[documentation-writing-alignment] Reconcile VS Code cleanup writes with the release-only permission rule #289

Context and request

Workflow authors need one explicit least-privilege rule for prerelease cleanup. The capability restricts write access to release while its design requires writes in a separate cleanup job.

Observed behavior

At reviewed source 4fbced2235bc621160a1b94832f50a5e1cbfa777, the specification's least-privilege principle says: Only the stage that creates the release has write access. The design's permission section first says only the release job elevates to contents: write, then names the separate PR-close cleanup job as the only other place that needs that permission.

Expected behavior and reproduction

Classify the release and PR-close cleanup jobs under both sections. The documents must define compatible permission scope, including whether cleanup is a permitted lifecycle exception. This is a documentation-contract comparison, not a finding about live permission configuration. The gap is retained from campaign baseline 1b0d4893c8fefabe604d04393068a8ff6f848082; a last consistent version and approved workaround are unknown.

Acceptance criteria

• Release and cleanup write requirements are explicit and compatible in spec and design.
• Cleanup remains limited to the intended prerelease resources and leaves stable releases unchanged.
• Validation jobs remain read-only by default; no broader permission is inferred from this clarification.

Technical decisions

Scope is the release/cleanup permission boundary. The owner must resolve the intended exception or requirement before implementation readiness. This capture changes no workflow, cloud access, token, repository role, or live permission and does not select a new authentication policy.

Implementation plan

• Record the conflicting job cases and owner-approved required scopes before editing.
• Reconcile the two sections in one focused documentation change.
• Repeat the cases and existing Markdown/link validation; verify actual producer permissions separately before making implementation claims.

References

Retained in MSXOrg/docs#253, not delivered or closed by MSXOrg/docs#267.