Declarative: evaluate non-secret drift detection for deferred !env plan values

Follow-up to #353.

The current direction for `!env` support is to resolve environment-backed values during planning for diff/update calculation, preserve the deferred reference in the generated plan artifact, and re-resolve from the environment again at execution time. This avoids persisting plaintext secrets in the plan artifact, but it means `apply --plan` may use a different value than the value observed during planning if the environment changes between runs.

This issue is to evaluate whether `kongctl` should support optional drift detection for deferred `!env` values without persisting the underlying secret value in the plan.

Ideas to evaluate:
- Store a non-plaintext marker derived from the planning-time resolved value
- Recompute the marker at apply time and warn if it differs
- Decide whether the marker should be per-field or per-change
- Decide whether warning-only is sufficient or whether strict failure mode is needed

Open questions:
- Is there a marker design that does not materially weaken secret handling for low-entropy values?
- Is the extra complexity justified versus a simpler generic warning that deferred `!env` values may differ at execution time?
- Should this be specific to `!env`, or a more general deferred-input mechanism?

This is intentionally out of scope for #353 so the initial `!env` implementation can proceed with clearer bounds.

Start by reviewing #353 and the planning plus `apply --plan` flow for deferred `!env` values. Evaluate marker designs, their secret-handling risks, per-field versus per-change scope, and warning versus strict behavior; done means a documented recommendation on whether and how to support drift detection.

Written by the indexing model from the issue text.