Lane-resolve additive PR merge conflicts

Epic siblings that touch shared hotspots (router tables, registries, list files) ping-pong in the merge lane: A merges, sibling B conflicts with develop, the lane fails B and re-opens its runner, B rebases and re-queues, C merges, and B conflicts again. Each round costs a full runner dispatch. (Split out of Task 8564, item 10.) Ask: - When a queued PR conflicts with the integration branch only on additive hunks (both sides only add lines), `tools/merge_lane.py` resolves the conflict itself: it merges the base into the PR branch with the hunks unioned, pushes that merge commit to the runner's `fleet/task-<id>` branch, re-pins the row to the new head, and gates the result as usual (P1 still holds). - Any non-additive conflict keeps today's path: fail the row and re-open the runner. - The timeline row that names a re-dispatch's cause (Task 8564) also names a lane-resolved conflict, e.g. "PR #424 conflicts — lane resolved". Out of scope: batching order, gate selection, the runner's own rebase prose. Done means: - A toolbox test where two PRs append different lines to the same list file: the second merges with no runner re-open and its head is a lane merge commit. - A test where the conflict is non-additive: the row fails as a conflict, as it does today.

Merge lane now resolves a runner PR's additive-only conflict with develop itself: it merges develop into the branch with the hunks unioned, pushes, and re-pins the row. Timeline shows "PR #N conflicts — lane resolved". Other conflicts fail as before. Tests and quick gate green; PR #6511 queued to the lane.