feat: add dispatch guardrails, NAS deploy-sync, and merge/teardown fixes

[inivosdigital]

Intent

Fix a safety bug in bin/fm-merge-local.sh: it pushed the project's default branch to 'origin' unconditionally whenever a local-only-mode project happened to have an origin remote, contradicting the documented local-only delivery contract (AGENTS.md section 6: 'local branch, no remote, no PR'). This risked silently publishing a captain's local-only work, or pushing to a tracking remote kept only for pulls.

The captain's explicit decision on the fix: scope the auto-push specifically to firstmate's own fork-sync case. This repo's own origin is the captain's fork (per the remote-swap and section 12's self-update model), and keeping that fork's default branch in sync after a local firstmate-repo merge is intentional, deliberate behavior worth preserving automatically. For every other local-only project, auto-pushing is not safe to assume, so it must be explicit opt-in via a new --push-origin flag rather than automatic.

Implementation: compare PROJ's canonical real path (cd + pwd -P) against FM_ROOT's canonical real path to detect 'this is firstmate's own repo', not merely 'any repo with an origin remote'. When PROJ is firstmate's own repo, or the caller passes --push-origin explicitly, the push happens (best-effort - a push failure is reported as a warning but never fails the merge, since the local fast-forward is the operation that actually matters). Otherwise the push is skipped silently, since not every local-only project is remote-backed. Added tests/fm-merge-local.test.sh (new) covering: firstmate's own repo pushes automatically; an arbitrary other local-only project with an origin does NOT push by default; that same project DOES push with --push-origin; an unknown second CLI argument is refused before touching the project; a non-local-only task is refused; and firstmate's own repo with no origin remote at all merges but skips the push silently with no warning.

Bundled in this same task (the captain asked to fix these properly here, since they were noticed during this review, rather than letting them ride along on an unrelated PR again):

1. bin/fm-teardown.sh: a forced teardown (--force) still ran the NAS deployment sync hook, even though --force carries no landed-work guarantee (it is the explicit discard path). Fixed by skipping that hook when FORCE=--force. Extended the existing test_local_only_force_overrides_unpushed test in tests/fm-teardown.test.sh to assert the NAS-sync hook's deterministic stdout line is absent when torn down under --force.
2. bin/fm-ultracode-guard.sh: the argument to 'flag' was written directly into the line-based state/.ultracode marker file with no validation, so a role containing a newline could inject a forged reviewed_by= line and bypass the independent-review requirement entirely. Fixed with a character-class validation (only letters, digits, '-', '_' allowed, non-empty) before writing the marker. Added three new tests to tests/fm-ultracode-guard.test.sh: a newline-injection payload is refused, a role with a disallowed character (space) is refused, and a role with digits/underscores is accepted.
3. bin/fm-bootstrap.sh: the upstream-drift refresh's bounded fetch (upstream_drift_fetch) used 'timeout' to cap a potentially-stalled 'git fetch upstream', but fell through to an UNBOUNDED fetch when the 'timeout' binary was not on PATH, defeating the whole point of bounding it (session start could hang indefinitely on a stalled network). Fixed by adding a 'gtimeout' fallback (the Homebrew-coreutils name for timeout), and a background-process-plus-kill-plus-elapsed-polling fallback as a final resort when neither binary exists. Added three new tests to tests/fm-bootstrap.test.sh proving each of the three bounding paths (timeout, gtimeout fallback, background-kill fallback) actually bounds a fake git-fetch that hangs 300s down to a few real seconds.

All four fixes and their tests pass locally (bash tests/fm-merge-local.test.sh, tests/fm-teardown.test.sh, tests/fm-ultracode-guard.test.sh, tests/fm-bootstrap.test.sh) and bin/fm-lint.sh plus shellcheck 0.11.0 (the pinned version) are clean across the full bin/.sh bin/backends/.sh tests/*.sh set.

The full-repo 'test' pipeline step is being skipped for this run on the captain's explicit decision: it runs the entire multi-hundred-file test suite (not just files touched by this diff), and it failed on two pre-existing, unrelated issues reproducible on main with unmodified files - tests/fm-backlog-handoff.test.sh requires tasks-axi 0.2.2+ (this machine has 0.1.2 installed) and tests/fm-afk-launch.test.sh has a flaky signal/lock-timing test - plus the pipeline's own auto-fix-tests step crashed on an unrelated 'argument list too long' infra bug. The captain accepted my own direct test runs of all four new/updated suites (all passing) and the clean bin/fm-lint.sh/shellcheck run as the evidence in lieu of the full-suite gate for this run.

This is firstmate's own repo (shared, tracked material per AGENTS.md section 1), so this task ships local-only: no PR, captain reviews the diff and approves, firstmate fast-forwards local main via bin/fm-merge-local.sh - the exact mechanism this task just fixed. The merge-push scoping change (the core fix) should go through the ultracode independent-review gate given its safety-sensitive nature (it governs when firstmate silently pushes to a remote), rather than routine validation alone.

What Changed

• Add mechanical dispatch quality guardrails: crew-dispatch model/effort tiers, a risk-tripwire safety floor, a resource-tier escalation guardrail, and ultracode independent-review flagging/tracking, hardened across several rounds of validation, portability, and race-safety fixes.
• Add NAS auto-deploy-sync to redeploy a project's live pm2 services after a landed ship task (bounded by a fetch timeout), per-worktree Docker Compose project isolation, and teardown recognition of work landed via fast-forward or local-only merge (skipping the NAS-sync hook on a forced teardown).
• Scope fm-merge-local.sh's automatic origin push to firstmate's own fork-sync case with a new opt-in --push-origin flag for other local-only projects, harden fm-ultracode-guard.sh's role marker against newline injection, bound fm-bootstrap.sh's upstream-drift fetch fallback, and surface failed critical systemd services at bootstrap.

Risk Assessment

✅ Low: This round's diff is a single, narrow six-line change to bin/fm-bootstrap.sh that faithfully implements the exact fix requested in round 1 (process-group kill via set -m / kill -TERM "-$pid" with fallback, mirroring fleet_sync's existing pattern and restoring monitor mode afterward); it's internally consistent, doesn't touch shared/global variable names in a way that conflicts with fleet_sync's own use of the same names, and the existing bounded-fetch tests only assert on elapsed time so they remain valid.

Testing

• ⏭️ Test - skipped

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

🔧 **Rebase** - 2 issues found → auto-fixed ✅

• ⚠️ AGENTS.md - merge conflict rebasing onto origin/main
• ⚠️ docs/scripts.md - merge conflict rebasing onto origin/main

🔧 Fix applied.
✅ Re-checked - no issues remain.

🔧 **Review** - 2 issues found → auto-fixed ✅

• ⚠️ bin/fm-bootstrap.sh:243 - The new last-resort fallback in upstream_drift_fetch() (used only when neither timeout nor gtimeout is on PATH) backgrounds git fetch directly and, on timeout, does kill "$pid" — signalling only the single git process. The comment claims this 'mirrors fleet_sync's own pattern below', but fleet_sync (lines 264-276) actually does set -m before backgrounding and kills the whole process group with kill -TERM "-$pid" (falling back to a plain kill only if that fails). If git fetch spawns a real child transport process (e.g. ssh for an ssh:// upstream), a plain kill $pid can leave that child running past the intended bound instead of being caught by the group kill. This is a narrow edge case (only reachable when both timeout and gtimeout are absent, uncommon on this fleet's Linux hosts) and is still strictly better than the prior unbounded fetch, but it doesn't fully match the pattern it says it mirrors.
• ℹ️ bin/fm-ultracode-guard.sh:88 - cmd_reviewed() still writes reviewed_by=$reviewer into the same line-based marker file without the character-class validation this diff just added for role in cmd_flag(). It's a much narrower surface in practice (a matching state/$reviewer.meta file must already exist, and task IDs are firstmate-generated kebab slugs), so it's not equivalent to the role-injection bug being fixed, but it's the same pattern left partially unhardened.

🔧 Fix: will report after background lint completes
✅ Re-checked - no issues remain.

⏭️ **Test** - skipped

Step was skipped.

✅ **Document** - passed

✅ No issues found.

✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.