Disable stop-hook auto-merge, auto-push, and auto-PR creation

[gnguralnick]

Summary

Repos created from this template are isolated units that grow with a particular user -- they must never be automatically synchronized with a remote. The code-guardian stop hook still did exactly that for worker agents: on every stop it fetched and merged origin/main into the working branch, pushed the branch to origin, and auto-created a PR (main/chat agents already had the hook fully disabled via their REVIEWER_*=0 template env). This disables the merge/push/PR machinery for every agent type while keeping the review gates (autofix, conversation review, architecture verification) intact for workers.

Changes

• .reviewer/settings.json: set stop_hook.fetch_and_merge=false and ci.is_enabled=false at the repo level. The plugin reads config per-key (env > settings.local.json > settings.json), so this also covers agents that never get a generated settings.local.json (e.g. worktree-template agents).
• .mngr/settings.toml: flip REVIEWER_CI_ENABLE to 0 in the worker and crystallize-worker templates. Their generated settings.local.json takes per-key precedence over the repo file, so leaving the env at 1 would have re-enabled the CI/PR gate for workers.
• scripts/build_workspace.sh: pin refs/remotes/origin/main to local main when the remote-tracking ref is missing. With fetching disabled, the stop hook's docs-only detection (git diff origin/main...HEAD) depends on a pre-existing remote-tracking ref. Docker-family workspaces inherit it from the clone baked into the image, but the lima path receives the repo via mngr's git-mirror transfer, which pushes only branches and tags -- the ref would never exist there, the diff would error silently, and every worker session would be classified as docs-only, skipping all review gates. The pin reproduces the docker-bake state; a real fetch (if one ever happens) overwrites it.
• CLAUDE.md: stop promising automatic PR creation and automatic CI runs (both came from the now-disabled CI gate); test/CI expectations are now conditioned on a PR existing.

Testing

• Simulated a worker's effective reviewer config (repo settings.json plus the settings.local.json that create_reviewer_settings.sh generates with the new worker args) and confirmed fetch_and_merge and ci.is_enabled resolve to false while autofix stays enabled.
• Functionally tested the ref-pin guard on scratch repos for both launch-path states: lima-like (no remote-tracking refs) gets the ref created and the hook's exact diff command then reports changed files; clone-like (ref present) is a no-op.
• uv run pytest from the repo root: 400 passed, 1 failed, 4 skipped. The single failure (libs/bootstrap/.../manager_test.py::test_detect_snapshot_settings_falls_back_to_direct_when_no_btrfs) is preexisting and environment-specific (findmnt is Linux-only; reproduced identically on base main on this macOS host).

Out of scope, deliberately: the post-commit auto-push hook and the runtime-backup service still push to the repo's own origin when GH_TOKEN is set -- those are the repo's backup mechanism, not stop-hook synchronization.

[joshalbrecht]

I changed some related code (to make the reviewer stuff a little less silly), but now there are conflicts

I like some of the general idea here (that we don't need to always auto fetch and push as part of the stop hooks, given that we're not always working with a git repo), though generally I'd like us to at least be able to support pushing to a git repo, and also, the stop hook still makes sense -- it's just that it should be merging changes in from the code in /mngr/code, for example

We should probably chat live about this one and what we want to do here!