fix(bin): resolve the fork trunk as a landing target

[sbracewell64]

The defect

The "has this landed?" check measured against a trunk this fleet does not land on, so proven-landed work read as unlanded and held its worktree slot indefinitely.

origin fetches kunchenguid/firstmate but pushes sbracewell64/firstmate. Both refs fm_landed_candidate_refs considered were wrong at once: refs/remotes/origin/main tracked upstream, and refs/heads/main had not been fast-forwarded since the fork trunk advanced five times that day. Nothing tracked the trunk this fleet actually lands on.

Measured on the held slot (PR 44, squash-merged, recorded head 2582c15, fork trunk f90ed1d):

check	result
git diff --stat 2582c15 f90ed1d	empty - content demonstrably landed
git merge-base --is-ancestor 2582c15 f90ed1d	false - squash, ancestry cannot hold
containment vs refs/heads/main	1 - proven not contained
containment vs refs/remotes/origin/main	2 - inconclusive
containment vs the fork trunk	0 - proven contained

The squash case is exactly what fm_landed_tree_contains exists to handle, and it works. It simply never saw the fork trunk.

The fix

The default fetch refspec cannot reach the fork, because it points at the fetch url. So:

• fm_landed_push_url resolves the push url when it differs from the fetch url. This is the same fetch-versus-push comparison bin/fm-task-base-lib.sh already made at the spawn site in fix(bin): separate task read and contribution bases (land of upstream #1613) #43; it now has one owner and both libraries read it - that one names the upstream side, this one the landing side.
• fm_landed_refresh_push_target fetches that trunk into refs/fm-landing/origin/<name>.
• fm_landed_candidate_refs offers it like any other candidate.

Why this is not a more permissive check

• The added ref is a landing target only because this fleet demonstrably pushes there. It is never inferred from a remote's name.
• Only a caller that already refreshes remotes performs the fetch, so bin/fm-worktree-guard.sh stays local and grows no network dependency.
• The three-way distinction is preserved. A push url that exists but cannot be read leaves the landing target unread, and teardown refuses rather than falling back to the upstream answer. That case previously passed on that fallback, so this direction is strictly stricter.
• A repository whose fetch and push urls agree resolves no landing ref at all and takes an identical path.
• No second landed-check was added; both call sites still run the one containment instrument.

Verification

Every negative control was watched red first.

Pre-fix, with the new tests in place:

not ok - fork-split-landed: teardown should succeed when the fork trunk holds the content: expected exit 0, got 1
not ok - fork-split-unreadable: teardown should refuse when the landing target cannot be read: expected exit 1, got 0
not ok - (o6) guard refused a slot whose content is on the fork trunk

The unlanded, upstream-only and single-remote controls pass both before and after, so they are not vacuous. All green post-fix.

Against real state, using the real remote urls, the real commits and a real network fetch:

resolved push url : https://github.com/sbracewell64/firstmate.git
landing ref named : refs/fm-landing/origin/main
containment vs upstream origin/main -> 2   (inconclusive - what held the slot)
containment vs FORK trunk           -> 0   (proven landed)

The same slot plus one genuinely unlanded commit still reports 1 (not contained), and with the push url made unreadable the refresh returns 1, which the caller must treat as a refusal.

New coverage: tests/fm-teardown.test.sh cases (u) through (y) and tests/fm-worktree-guard.test.sh cases (o6) through (o8).

Test run

Full changed-scope selection: 75 scripts, 69 pass, 6 fail. Those 6 fail identically on the unmodified fork trunk - tmux readiness, node ESM module resolution, and harness env vars - so they are pre-existing and environmental. Zero new failures. bin/fm-lint.sh and bin/fm-doc-audience-check.sh both clean.

Known limitation, disclosed

Teardown now performs one additional network fetch per cleanup on a fetch/push-split home. The existing origin fetch already carried the same exposure and neither has a timeout, so this is not a new class of failure, but it is one more remote read on that path.