Root-cause follow-up to #733. `_resolve` (the actual API-targeting resolver)
already prefers the workspace-aligned git remote over the `REMOTES` default
(bare `prgs` -> Scaled-Tech-Consulting/Timesheet). The shared #604 anti-stomp
preflight (`_run_anti_stomp_preflight`) did not mirror that: for every mutation
task whose call site omitted org/repo it filled the remote-wide `REMOTES`
default, so the #530 repo guard false-positived `wrong_repo` against a
Gitea-Tools checkout and blocked native issue/PR/review/merge/lock/cleanup
mutations at preflight — even though the resolve stage would have targeted the
workspace repo correctly.
Fix: for omitted coordinates, `_run_anti_stomp_preflight` now prefers the
trusted git-remote-derived workspace identity (marking those filled sides
explicit, exactly like `_resolve`) for session-bound mutation tasks. This fixes
every remaining preflight call site at the shared chokepoint without changing
the global `REMOTES` prgs default (still the best-effort last resort when no
workspace identity can be derived). `delete_branch` keeps its explicit
cross-repository target contract (#733) via `_EXPLICIT_TARGET_MUTATION_TASKS`
and still fails closed on omitted coordinates.
Tests: tests/test_preflight_workspace_repo_forwarding.py (session-bound
resolution across 20 tasks, #530-guard pass, explicit-coords passthrough,
no-workspace REMOTES fallback, delete_branch contract preserved). Full suite
3228 passed / 6 skipped / 240 subtests (1 pre-existing env-leak failure in
test_issue_702_review_findings_f1_f6, fails identically on baseline master).
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
