fix(execution): quantize bracket prices to the venue tick, in opposite directions (#802)

[eaitbrahim]

Closes #802.

The bug

Sizes were quantized (#513/#516). Prices were not.

2026-09-16 03:44Z, keel-live.db order id 5
executor.order_rejected  PAXG-USD SELL  error='Too many decimals in order price'

_bracket_spec floored base_size and passed stop/target straight through, so
4521.76390215979454 went on the wire. sizing.quote_increment_for looks like it covers this
and does not — its own docstring says "the venue's finest acceptable quote_size", it is
keyed on the CURRENCY not the product, and it is applied in one place: a BUY's notional.

Every protective bracket was rejected. All three positions on the live deployment carry
bracket_order_id = NULL, and the stop-loss/take-profit machinery has never fired there. Nothing
distinguished that from DCA's legitimate bracket-lessness, in any surface.

Direction is the substance, not a detail

quantize_down is documented as the safe direction for sizes — rounding a size up spends
more than guards.check authorised. That reasoning does not transfer to a protective stop:
rounding a long's stop DOWN moves it further from price and widens the loss the position was
sized against, silently, on every bracket.

So:

price	direction	why
stop_trigger_price	up	toward safety — never widen the risk the position was sized on
take_profit_price	down	toward reachability

quantize_up is a separate function, not a flag on quantize_down, because the two are
justified by different arguments and a flag invites picking the wrong one by habit.

Note Decimal.__floordiv__ truncates toward zero rather than flooring, so the usual
-((-v) // i * i) ceiling idiom silently returns the floor. It steps up explicitly instead, with
a comment saying why.

A collapsed pair is refused, not sent

The two prices round toward each other, so a coarse tick can invert a pair that was valid before
it. That raises BracketPricesUnplaceable rather than reaching the venue.

And the #799 shape is closed while we're here

_bracket_spec was an inline argument to _run_order, so anything it raised left
place_bracket past the if not result.placed recovery — exactly how a filled PAXG entry was
stranded for three weeks. It is now built inside a try, and a bracket that cannot be BUILT is
the same event as one the venue REFUSES: levels recorded to unbracketed:, a WARNING, a retry
next cycle. There is a test asserting the retry record holds the RULE's unrounded levels.

Where the tick comes from

Instrument.quote_increment, the field its own docstring anticipated ("would sit here naturally,
but nothing reads them yet, and a field no caller reads is a field no test meaningfully checks").
It rides the existing per-product fetch and the existing cache record, so no extra venue
round-trip enters the order-placement path. A pre-#802 cache record simply reads as unknown until
it expires, which is correct — nothing knew the tick when it was written.

Unknown stays unknown: prices go unrounded, never refused. Refusing would leave a filled position
with no stop at all, which is the #799 outcome.

Verification

Mutation: reusing quantize_down for the stop — the fix that still puts prices on the tick and
would pass a naive "is it rounded?" check — is killed by three tests.

ruff check keel tests packages   -> All checks passed!
ruff format --check .            -> 503 files already formatted
mypy                             -> clean (465 files; pre-existing PyYAML stub note only)
pytest                           -> 6651 passed, 3 skipped

Deployment note

The live PAXG position is currently retrying its bracket every cycle and escalating
reconcile.position_unprotected at CRITICAL. This is what lets that retry succeed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AoGRoExgHVCsWDHT3ej8mD