_clean_ref base parser: a backtick span in trailing prose still wins over the @-token (recurrence of #235, other direction)

[eduralph]

Routed from a downstream Act review (getwyrd/wyrd-pdca, 2026-07-07), bundle #454. This is a recurrence of #235 in a shape its fix did not cover — #235 closed COMPLETED (2026-07-04) handling the parenthetical base main (… \feat/…`), but the same _clean_ref` "a backtick span wins over the first token" behaviour still mis-resolves a different input.

Symptom (bundle #454)

The publish / C4-verify base parser (_brief_base / _clean_ref) takes the first backtick span anywhere after @, so a backticked branch name in a trailing prose aside hijacks the base:

getwyrd/wyrd @ feat/m4-production-metadata-backend   (… not on `main`)
                                                            ^^^^^^  ← this wins

resolves base = origin/main instead of feat/m4-production-metadata-backend. Consequences:

• C4-verify false-fails ("patch does not apply — stale") because the patch is validated against the wrong base.
• publish would open the slice PR against the wrong base branch.

This is the opposite direction from #235 (which resolved to the parenthetical branch); both stem from letting a backtick span other than the intended base token win.

Root cause

_clean_ref does not anchor to the base token position — it scans for a backtick span. #235's fix special-cased the parenthetical form; a bare backtick span later in the string still wins.

Ask

• Anchor the parse to the token immediately after @ (the base ref), and never let a backtick span elsewhere in the base string override it — covering both directions (parenthetical branch and a backtick in a trailing prose aside).
• Add the #454 input as a regression case alongside the Worktree isolation silently falls back to in-place: publish._clean_ref mis-parses a parenthetical base — must fail closed #235 parenthetical case.

Related: #235 (parenthetical form, closed COMPLETED) — this is the residual its fix left open. Downstream context: getwyrd/wyrd-pdca bundles #252 (#235's origin) and #454 (this recurrence).