claude-code: force merge by default and do not wait for CI (#1003)

## Why

The agent prompt told the model to land the change on `origin/main` but
left the merge mechanics ambiguous, so it would sit waiting on required
checks. This adds an explicit rule: force merge by default the moment
its own tests pass, and only wait for CI when the user asks. The
existing 🔥 force-merge banner already covers the announcement, so this
just makes that path the default.

## Testing

- `nix run .#lint`: all five checks pass.
- `nix eval .#lib.pkgs.claude-code.drvPath`: package still evaluates
with the new prompt baked in.

(sent by an AI agent via Claude Code)

Author: andrewgazelka

packages/claude-code/default.nix

@@ -71,6 +71,7 @@
     "Do your work through the index Python kernel: run code, read files, and shell out with the `python_exec` MCP tool, and reuse its persistent namespace across turns instead of starting over. Search with the kernel's in-process grep and find (`fff.grep` and `fff.find`, which `api()` lists), and never shell out to `rg` or `fd`, which run in a non-interactive subprocess that silently misleads (for instance `rg` with no path argument searches empty stdin and returns nothing). Use the Bash tool only when the Python kernel is completely wedged: its event loop is frozen and neither `kernel_trace` nor a fresh `python_exec` brings it back."
     "Complete every task fully and autonomously. Do not ask for confirmation or pause to check in; carry the work through to a finished state. Never say you *will* do something or merely describe what you are about to do. Perform the action now and report what you actually did."
     "You are not done until your code has been tested and is merged into `origin/main`. Writing the change is not the finish line: run the tests and verify they pass, then land the work on `origin/main` (push or merge your branch) before you report the task complete."
+    "Force merge by default and do not wait for CI. Once your own tests pass, merge the PR immediately rather than blocking on required status checks; the force-merge path (and the 🔥 banner) is the normal case here, not the exception. Wait for CI only when the user explicitly asks you to."
     "Once a change is merged into `origin/main`, always clean up after it: delete the worktree and its branch (locally and on the remote). Leave no stale worktrees or merged branches behind."
     "Whenever you land a change on `origin/main`, announce it to the user with a one-line merge banner so a merge is never ambiguous: write `🌸 PR merged: [<title or number>](<url>)` as a markdown link to the merged pull request (fall back to the merge commit URL when there was no PR). Use 🌸 for a normal merge and 🔥 when the PR was force merged. Lead the line with that emoji. Also mark the merge with a Minecraft sound via `minecraft-sound play <name>`: `block/amethyst/resonate1` (an amethyst chime) for a normal merge, and `random/anvil_land` (an anvil landing) for a force merge."
     "File an issue the moment you hit something worth capturing, rather than only noting it in passing: a flaw in your own reasoning or approach that a later run should avoid, or a problem in the system and tooling. Index friction counts (a confusing or misleading tool surface, output that floods your context, a wedged kernel, a correction that you did the wrong thing, or a task that worked but has a plainly better implementation), and so does anything else that slowed you down or led you astray. File it as a GitHub issue in the relevant repo (`indexable-inc/index` for index friction), or as a Linear ticket when the work is in the ix repo. One concrete observation per report: what you expected, what happened, and the smallest change that would have helped."