delete() has no secret masker, and the delete bag CAN carry plaintext on the in-process rollback path #2007

Summary

Issue #1932 item 3 added SecretMaskingContext.maskSecrets to CreateContext
and UpdateContext. DeleteContext was deliberately left without it. This
issue records the residual, because the FIRST rationale written for that
exclusion was factually wrong and the corrected one is narrower than it sounds.

The bag CAN carry plaintext (the wrong rationale)

The shipped comment originally claimed every delete() call site hands the
provider a bag read from cdkd STATE, which holds the redacted
{{resolve:...}} expression. That is false. Trace:

1. deploy-engine.ts CREATE writes
   properties: this.propertiesToRecord(resolvedProps, result) into the
   IN-MEMORY stateResources map — resolvedProps is RESOLVED PLAINTEXT.
2. Redaction happens at the SAVE choke point: redactStateForPersist builds a
   NEW record per resource via scrubResourceRecord and never mutates the
   in-memory one.
3. performRollback hands that same in-memory map to replayRollback.
4. rollback-executor.ts's reverse-replacement delete arms read
   current.properties straight off it (current = stateResources[op.logicalId]).

So an in-process rollback can hand a provider delete() a bag carrying a
concrete secret. The comment now states the narrower true thing: no provider
delete() interpolates a property value into a log line today.

Why the capability was NOT added in that PR

Not effort — correctness. Threading it is not the mechanical change it is on
the create / update side:

• The plaintext in current.properties was resolved by the deploy, whose
  bag lives in DeployEngine.perResourceSecrets.
• RollbackExecutorContext has no secrets field.
• The executor's own per-op map is built by re-resolving
  previousState.properties — the previous generation.

A delete-side masker bound to that per-op map would therefore miss exactly the
value it exists to catch whenever the two generations differ (a rotated secret,
or a property only the new generation carries). That is protection which fences
nothing, and it is worse than no capability at all, because its presence stops
the next author looking.

What doing it properly needs

1. A secrets field on RollbackExecutorContext, populated from
   DeployEngine.perResourceSecrets in rollbackExecutorContext(), keyed per
   logical id — with a decision about which bag wins for an op whose previous
   and current generations resolved different values.
2. DeleteContext extends SecretMaskingContext. DeleteContext lives in
   src/provisioning/region-check.ts while SecretMaskingContext lives in
   src/types/resource.ts, which imports DeleteContext back — so the shared
   base likely has to move to the src/deployment/secret-redaction.ts leaf
   (zero imports) to avoid a type-level cycle.
3. Threading at the 10 plaintext-capable delete sites (5 in
   deploy-engine.ts, 5 in rollback-executor.ts).
   destroy-runner.ts's single site reads state from S3, which IS redacted, so
   it has nothing to mask.

Interim rule (already in the code and docs)

SecretMaskingContext and .claude/rules/providers.md both state it as a MUST:
before adding any delete() log line that interpolates a property value, thread
the capability first. Do not read the absence of maskSecrets on
DeleteContext as evidence that a delete bag is safe to print.

Note #1997's provider list was audited for create / update log lines only, not
for delete ones.

Session-fit: next (not this session) — needs new cross-component plumbing
(RollbackExecutorContext ← DeployEngine.perResourceSecrets) plus a design
call on which generation's bag wins, and it has zero consumers today /
Effort: ~3 h+ (the plumbing, a type move to break the cycle, 10 threading
points, unit matrix, and a review round)

Consumers found later, folded here rather than filed separately

The missing secrets field on RollbackExecutorContext (item 1 above) is the
precondition for more than the delete-side masker this issue was filed for.
Each row below is a distinct consumer blocked on that same plumbing.

• rollback-executor.ts nested-stack parameter collapse -- DONE, and the
  premise recorded here when it was folded in was WRONG. It was filed as
  blocked on item 1 above; it was not. secrets is hoisted to the top of the
  revert arm and already in scope, with the resolved plaintext and the
  expression-bearing JOURNAL both in hand, so no new plumbing was needed --
  and item 1's "wrong generation" objection does not apply, because a rollback
  WANTS the previous generation's expressions, which is the generation it is
  reverting to. Fixed in the fix(secret-redaction): two child Parameters resolving to ONE plaintext collapse onto a single expression, so a nested-stack leaf persists its siblings version stage #2291 PR: the three resolution arms
  that feed the four withCurrentResourceSecrets binders now record from the
  journal under STATE_DERIVED_RULES, DESIRED side only. Left here rather
  than deleted so the wrong premise is visible instead of quietly removed.

• s3-directory-bucket-provider.ts notEmptyRefusalMessage (the delete-path not-empty refusal): renders aws s3 rm s3://<recorded bucket name> with no masker, so a secret-derived bucket name prints on destroy. Found by the fix(provisioning): the ASG / ELBv2 deletion-protection remedy pastes a pre-rotation secret-derived name unmasked #4339 sweep of every renderDisableCommand caller. It is a delete-path site, so it waits on this issue's DeleteContext masker. Low severity: destroy-time, and only for a secret-derived directory bucket name.