Phase 6 hardening for #1010: count partially_filled as the window's buy; fix the promotion-floor docstring #1015

Two minor findings from the independent whole-range review of PR #1013 (787e0cd..c7f3505). Neither is a blocker; both go into #1013 before it merges.

F1 — partially_filled is not counted as the window's buy. Repository.last_live_buy_created_at (keel/data/repository.py:801) counts status IN ('filled', 'pending'). execution/reconcile.py moves a row with 0 < filled_size < qty to the non-terminal partially_filled ("the venue has begun executing it", reconcile.py:75). Trigger: a DCA buy raises after its row is written, the row stays pending, the next cycle's reconcile sees a partial fill and sets partially_filled; the next fresh bar in the same window then retries and buys again. Unlikely for an IOC market order, but it is the exact double buy the window ledger exists to prevent. Fix: count partially_filled too, with a test that seeds such a row inside the window and asserts no retry.

F3 — docstring overstates the promotion floor. keel/agent.py:378 says flooring promoted_at to midnight "keeps the first live bar". When a rule is promoted earlier on the same UTC day as its first live cycle, that cycle acts on bar p-1, which is excluded, so a veto on it is never retried. That errs toward not buying and R13 accepts it; only the wording is wrong. Fix: say so.

Noted, not changed: a ledger read failure plus two live cycles in one day restores the pre-#1010 double-buy (accepted under R14; the live wrapper runs once per UTC day). The rail 15/20 comments at guards.py:1035 and :1152 group rails by entries-only, not by DCA exemption; left as is.

🤖 Generated with Claude Code