fix(tier2-sandbox): add git stash* and git clean -fd* to all 3 ban layers; spell out timeline-is-immutable principle

ROOT CAUSE: Tier 2 used 'git stash' during the cruft_elimination_20260627
track execution and corrupted the user's in-progress files. The user
explicitly stated: 'if an agent fucks up, their tendency to want to revert
is not correct and instead they must live with the timeline and just do
corrections with a new commit. They can grab artifacts, code, etc, from
old commits but they cannot reset to that.'

This commit adds HARD BANs on git stash* and git clean -fd* at 3 layers
(per the existing 3-layer defense model documented in
conductor/tier2/agents/tier2-autonomous.md):

LAYER 1: AGENTS.md
- Added new HARD BAN: 'git stash* (any form: git stash, git stash pop,
  git stash apply, git stash drop, git stash clear) is FORBIDDEN.
  Stashing inverts the safety net of the working tree'

LAYER 2: conductor/tier2/opencode.json.fragment (Tier 2 autonomous)
- Added 'git stash*', 'git stash pop*', 'git stash apply*',
  'git stash drop*', 'git stash clear*', 'git clean -fd*', 'git clean -fdx*'
  to BOTH the top-level permission.bash deny list AND the
  agent.tier2-autonomous.permission.bash deny list
- Also added 'git revert*' (was missing from fragment; already banned in prompt)
- These are now HARD DENIED at the OpenCode permission layer; the agent
  cannot run them even if it tries

LAYER 3: conductor/tier2/agents/tier2-autonomous.md
- Added 'git stash* (any form)' to the Hard Bans list
- Added 'THE TIMELINE-IS-IMMUTABLE PRINCIPLE' section spelling out
  exactly what to do when you fuck up:
  - When you make a wrong commit, write a NEW commit that fixes it
  - The git history is immutable on this branch
  - You CAN grab artifacts from old commits via 'git show <sha>:<path> > <new-path>'
  - You CANNOT reset the branch HEAD to an old commit
  - 'git revert', 'git reset --hard', 'git reset --soft', 'git stash' are
    all attempts to rewrite history and BANNED
  - Correct pattern: pause, read the actual file, write a forward
    corrective commit with a commit message that explains the fix

This addresses the root cause of the 2026-06-27 cruft_elimination
corruption. Future Tier 2 autonomous runs will be blocked from running
git stash* at 2 layers (OpenCode permission deny + Tier 2 prompt hard
ban list) and reminded at the agent-prompt layer (THE TIMELINE-IS-
IMMUTABLE PRINCIPLE section).

conductor/tier2/agents/tier2-autonomous.md

@@ -83,9 +83,35 @@ This gate catches the failure mode in the 2026-06-24 MCP regression where Tier 2
 - `git checkout*` (any form) - use `git switch -c` for new branches, `git switch` to switch
 - `git restore*` (any form) - do not restore files (per AGENTS.md hard ban)
 - `git reset*` (any form) - do not reset state
-- `git revert*` (any form) - per AGENTS.md hard ban; use FIX-IF-FAILS (amend or fixup commit) instead
+- `git revert*` (any form) - per AGENTS.md hard ban. **THE TIMELINE IS IMMUTABLE**: when you fuck up a commit, you LIVE with the timeline and do a CORRECTION with a NEW commit. You can grab artifacts, code, or files from old commits via `git show <sha>:<path> > <new-path>` or `git checkout <sha> -- <path>` (note: `git checkout <sha>` for FILE extraction is allowed; `git checkout <branch>` to switch is BANNED). But you CANNOT reset the branch HEAD to an old commit and pretend the wrong work never happened. The wrong work is part of history now; the fix is a follow-up commit that supersedes it. **NEVER use `git revert`, `git reset --hard`, or `git reset --soft`** to "undo" a bad commit — always go FORWARD with a corrective commit.
+- `git stash*` (any form: `git stash`, `git stash pop`, `git stash apply`, `git stash drop`, `git stash clear`) - per AGENTS.md hard ban (added 2026-06-27); stashing throws away the user's in-progress edits silently. If you think you need a stash, you don't - use a NEW BRANCH or a WORKTREE instead. The 2026-06-27 `cruft_elimination_20260627` track was corrupted by Tier 2 using `git stash` and losing the user's in-progress files.
 - File access outside the Tier 2 clone - the OS blocks it. **NEVER USE APPDATA** for any read, write, or shell command; the `*AppData\\*` bash deny rule will halt the run if you try.
 
+### THE TIMELINE-IS-IMMUTABLE PRINCIPLE (added 2026-06-27, after the cruft_elimination corruption)
+
+When you (the agent) fuck up — make a wrong commit, break a file, take a bad path — your first instinct will be to "undo" the mistake with `git revert`, `git reset`, or `git stash`. **THIS INSTINCT IS WRONG.** The user explicitly stated: "if an agent fucks up, their tendency to want to 'revert' is not correct and instead they must live with the timeline and just do corrections with a new commit."
+
+**The rule:**
+- The git history is IMMUTABLE on this branch. Every commit you've made is part of the record.
+- "Undoing" via `git revert` / `git reset` / `git stash` makes the user's review harder, not easier (the user has to read the diff between the bad and the "fix" to understand what went wrong).
+- "Fixing forward" via a new commit makes the user's review EASIER: they can see exactly what changed between the bad commit and the fix.
+
+**Correct pattern when you fuck up:**
+1. Pause. Read the actual file. Confirm the state.
+2. Write a NEW commit that fixes the problem. The commit message should briefly say what was wrong and what you fixed.
+3. If the bad commit introduced data corruption that the user will see, the user can `git revert` it during their review — that's the user's choice, not yours.
+4. If you need to recover an old version of a file (because the bad commit destroyed it), use `git show <good-sha>:<path> > <path>` to extract it. The bad commit is still in history; you're just reading from history to recover.
+
+**Wrong pattern (which you must NOT do):**
+- `git revert <sha>` to undo a commit
+- `git reset --hard <sha>` to throw away a bad commit
+- `git stash` to "save" uncommitted work (it just disappears when you lose the branch)
+- `git checkout <old-sha> -- .` to "go back to when things were good" (and then commit on top)
+
+These are all attempts to rewrite history. They are BANNED. The right answer is always a forward commit.
+
+**Concrete example:** if you realize commit N introduced a bug, write commit N+1 that fixes the bug. The user can see both commits in the diff and understand the full story. The user's CI / reviews / git log will all show both commits, which is what they want.
+
 ## Conventions (MUST follow - added 2026-06-17; updated 2026-06-27)
 
 - **Test runner:** ALWAYS use `uv run python scripts/run_tests_batched.py` for test runs. NEVER call `uv run pytest` directly. The batched runner provides tier-based filtering, parallelization (xdist), and a summary table. Direct pytest is slow and bypasses the tiering that the live_gui tests depend on.

conductor/tier2/opencode.json.fragment

@@ -51,7 +51,15 @@
       "git push*": "deny",
       "git checkout*": "deny",
       "git restore*": "deny",
-      "git reset*": "deny"
+      "git reset*": "deny",
+      "git revert*": "deny",
+      "git stash*": "deny",
+      "git stash pop*": "deny",
+      "git stash apply*": "deny",
+      "git stash drop*": "deny",
+      "git stash clear*": "deny",
+      "git clean -fd*": "deny",
+      "git clean -fdx*": "deny"
     }
   },
   "agent": {
@@ -82,7 +90,15 @@
           "git push*": "deny",
           "git checkout*": "deny",
           "git restore*": "deny",
-          "git reset*": "deny"
+          "git reset*": "deny",
+          "git revert*": "deny",
+          "git stash*": "deny",
+          "git stash pop*": "deny",
+          "git stash apply*": "deny",
+          "git stash drop*": "deny",
+          "git stash clear*": "deny",
+          "git clean -fd*": "deny",
+          "git clean -fdx*": "deny"
         }
       }
     }