**Item 3 from the closing bar.** Behaviour change, own commit.
## The defect
`resolveReplanTargetColumn` fell back to the literal `"triage"` when a
workflow declared neither legacy planner id. That names a column the
workflow doesn't declare — and since #2515 the **default lineage doesn't
declare it either**, so the fallback pointed at a column that exists
nowhere. The replan move then either failed outright or put the card
somewhere no sweep owns.
Resolved through `resolveReboundTarget` (KTD-10: hold → intake → first
declared) — the same helper every other rebound path uses, so replan
lanes and rebound lanes stay consistent instead of drifting.
## The catch path keeps its literal, deliberately
It's reached only when resolution **throws** — not when it silently
falls back to the default IR, which returns a real workflow and takes
the `todo` branch above. With no IR there's nothing to resolve, and
swapping one arbitrary literal for another changes behaviour without
evidence about the workflow. Documented at the site so the asymmetry
reads as a decision, not an oversight.
## Test
Written first and observed **red**. It asserts the target is a column
the workflow actually declares:
```ts
expect(workflowHasColumn(ir, target)).toBe(true);
```
rather than pinning a specific id — so it can't pass by naming a
*different* wrong column, which is how the previous version of this test
stayed green while the fallback was broken.
**Mutation-verified:** restoring the literal fails it.
## Verification
40 replan-target tests green, engine tsc clean, lint clean, merge gate
green (487 + 132 + 10).
No changeset: `@fusion/engine` is private.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
f5cc416ae4