Workspace mutation reporting: honest enforcement fields, drop the dead write_generated_or_ignored enum

[cf-pages]

Targeted: 0.5.0. Baseline: release/0.3.0.

Scope decision (maintainer, 2026-08-13): the structured-only enforcement mode is dropped, not deferred. Survey of current practice found no precedent or requirement for "source edits must go through the structured tool": Codex CLI's workspace-write sandbox keeps the whole workspace shell-writable (only .git/.codex metadata stays read-only, an escalation control), Claude Code's sandbox enforces the workspace/host boundary and temp dirs, and "no-shell" MCP servers simply do not expose exec at all. The industry-enforced boundary — workspace vs host — is already enforced here by Landlock. A structured-only workspace would break git commit, __pycache__, and every toolchain's build outputs (Landlock's path-beneath model cannot express "writable directory except these files", nor bind rules to paths that do not exist yet) for a guarantee nobody mandates.

What remains in scope (zero risk):

• server_info reports workspace_mutation_policy and workspace_mutation_enforcement honestly (today: unrestricted, enforcement = workspace-boundary via Landlock where available).
• check_exec_environment warns on non-Linux platforms that static command scanning cannot prove side effects of arbitrary programs.
• Project instructions steer models to prefer apply_changes / apply_patch for source edits (guidance, not enforcement).
• Remove the write_generated_or_ignored enum value from the exec schema: never implemented, never raised; keeping it advertises a negotiation model that does not exist.

Noted for the future, out of scope: Codex-style protected metadata (read-only .git/hooks within a writable workspace) is a real escalation control worth considering separately — orthogonal to structured-only.