Expose plan warnings/diagnostics in the plan policy input

Workaround

Yes, at the cost of a second plan on every run. An after_plan hook re-runs "tofu plan -json -refresh=false", extracts warn-level diagnostics into a custom plan policy input, a plan policy turns them into run flags, and a notification policy reads the flags and posts to Slack. -refresh=false keeps it cheap, but this is going on every stack, so it roughly doubles plan invocations account-wide. Being a separate evaluation, it can also drift from the plan Spacelift actually recorded. Also ruled out: TF_CLI_ARGS_plan=-json (output goes to the log collector, not to a file a hook can read) and a CUSTOM workflow tool piping the plan: command through tee (works, but we'd own the plan argument template and exit-code handling on every stack).

Problem

Plan-phase warnings only exist in the run log, so nothing can act on them — no alerting, no gating, no tracking. We can't answer "which of our stacks are emitting provider deprecation warnings?" without opening each run by hand. These warnings are advance notice of breakage. A real one from our plans: "2 attributes specified when one (and only one) of [rule[1].expiration[0].date, ...] is required — This will be an error in a future version of the provider." We'd like to catch that before a provider upgrade, not during one. Use case: Slack alert to the owning team when a stack's plan emits warnings. Secondary: a plan policy that blocks newly introduced deprecated usage while tolerating what already exists. No existing surface reaches them. The notification policy input has no such field. "tofu show -json <planfile>" has no diagnostics key, so input.terraform can't see them either. And spacelift::logs::planning is webhook-payload only, substituted after the policy is evaluated, so a policy can never branch on log content.