Two linked changes that together close the "enforcement isn't
automatic enough" gap surfaced in 0.2.2 live-testing:

1. Codex developer_instructions (steering)

   In 0.2.2 the live test had to say "use agentsid_shell_run to run
   sudo echo hi" for the guard MCP to even fire. Without that explicit
   tool name, Codex defaulted to its native `shell` tool and the guard
   never saw the call. Codex supports a top-level `developer_instructions`
   string in config.toml ("Additional developer instructions injected
   into the session" per https://developers.openai.com/codex/config-reference).

   The wizard now writes a ~100-word instruction string telling the
   agent to (a) prefer agentsid_* MCP tools when available, (b) treat a
   BLOCKED response as a hard policy denial, (c) NOT retry with a native
   equivalent. Concise by design — longer prompts degrade compliance.

   Two new tests assert the key is present + contains the required
   phrases ("agentsid_shell_run", "prefer", "do NOT retry"), and one
   serialisation test confirms it lands above any [table] header per
   TOML ordering rules.

2. Preset rules for .secrets / credentials / *.token

   Server-side classifier shipped the matching tags in commit 5932c18
   (deploys to Railway on push). This commit adds the matching
   DENY_SECRETS_FILE, DENY_CREDENTIALS_FILE, DENY_TOKEN_FILE rules to
   both Developer and Security-Team presets, plus a new
   `credentials.secrets` wizard toggle that bundles them.

   `.envrc` (direnv) doesn't need a new preset rule — the classifier
   now emits the existing `file.read[.env]` tag for `.envrc` basenames,
   so the existing DENY_ENV_FILE rule catches it automatically.

Verified locally: 112/112 tests pass, tsc --noEmit clean, TOML dry-run
shows developer_instructions lands in the right position with all
agentsid_* tool names correctly quoted. Live-verification that Codex
now picks agentsid_shell_run by default is the next step.