Task: Flip the bond security

The bond planner states the security the trade holds, and the writer sends it without reading a bag.

• The planner constructs the issue with its leg, amount and rate rows, and the batch carries them.
• The writer's ensure_issue takes the constructed row and reads no bag.
• bond_terms is gone from the plan, and a provisioning run books the same 24 bonds.

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

ensure_issue writes a put_bond_issue_composite_request: one bond_issue row (issue id, security id, issuer, face value, issue date, settlement days, calendar, sub type, price type, curve) plus one leg, one notional amount and one fixed rate. It runs before the trade is booked, because the instrument points at an issue that must already exist.

So this slice moves about sixty lines from the writer to the planner and gives the batch the rows the request already holds. It is not a rename: the leg, the amount and the rate are part of the security, and the planner has to state them with the issue's own identifiers.

The instrument flip kept terms precisely because this coupling exists, and the planner's tests caught it. Moving the security is the step that lets bond_terms leave the plan, so it is the step that starts deleting the bag.

The bond security states its rows. The planner builds the issue with its leg, its notional and its coupon, its rate and its schedule rule, and puts them in the batch beside the instrument; the writer packs them into the composite write, stamps every row and sends. It decides nothing about the issue now: the terms were drawn where the security was drawn.

The bag is deleted. `trade_terms` and the slot's `terms` member are gone, every family's planner keeps its own drawing struct, and the writer's dispatch has no bag arm left. That was the story's endgame: the slot states rows, and one structure describes each family's drawing rather than what a slot carries.

The population is unchanged: 24 bond instrument rows, 16 issues with a leg, a rate, a schedule and a notional-plus-coupon pair each, no instrument without its issue, and 127 trades in total.

One number moved and the record should say so. An earlier run on the same population counted 18 issue rows where this one counts 16. The issue table is versioned and that count includes every version, so a re-written issue adds a row; the current run holds sixteen securities, sixteen live issues and no orphan instrument, and no test or provisioning step depends on the version count. It is noted rather than explained because the earlier database is gone.

The task document reached this branch late: the story listed the row, but the doc itself was never merged from its scaffold branch, so the table held a row with no link until this PR brought the doc with it.