C2-5: POS and till on the contract (ADR 0005)

[futurebuildai]

C2-5: POS and till (ADR 0005 section 14.2, migration 105 pos_wire_contract)

The counter onto the wire contract: lines in the shared salesdoc shape, cents tenders, the walk-in customer, and a completed sale as ONE transaction (stock out, the invoice posted through the AR core with tax and COGS, one payment per tender applied and stored net of change, an ACCOUNT tender open under the credit check). The void of the completed sale while its drawer is open reverses exactly what it posted; a return is a credit memo created, posted, refunded and restocked in one act. The post commit best effort GL calls, the fake product line under a split tender, and the hard coded USD card charge are gone.

14.2 C2-5 lines, each with its test (fail first: every behaviour below was red against the base commit's shapes or refused; the carried WIP proofs were fixed red first in 88ba873/d7fffde)

ADR 14.2 line	Test
Lines in the shared shape (product, charge and text at the counter, typed override and discount with audit, kits exploding)	TestSaleWireShape (the audit rows each adjustment owes asserted beside the shapes)
Cents tenders	TestSaleWireShape, TestSplitTenderSalePostsEveryEntryInTheSaleTransaction (a decimal tender is a decode error, never a rounding)
The walk-in customer; ACCOUNT refused for it	TestWalkInSaleRefusesAccountTender, and migration 105's walk-in in TestMigration105_POSWireContract
The completed sale one transaction: stock out, invoice (origin POS, pickup) with tax and COGS, tenders as payments applied and stored net of change, ACCOUNT open under the credit check	TestSplitTenderSalePostsEveryEntryInTheSaleTransaction, TestChangeIsNeverSubtractedTwice
A failing event or audit write rolls every write back (no invoice, payment, stock move or entry)	TestFailingEventWriteRollsTheSaleBack (both the completion and the void; the gapless series spends nothing)
The void while the session is open, one transaction in section 11's order (sale, payments, invoice); the card refund at the gateway before it	TestVoidOfACardSaleLeavesTheLedgerAtZero, TestVoidAfterSessionCloseIsRefused
After the session closes it is a return	TestVoidAfterSessionCloseIsRefused
A return is a credit memo created and posted in one act with its restock lines, refunded cash or card or left as account credit	TestReturnRestocksAndReversesCOGS, TestAccountReturnLeavesOpenCredit
A split tender posts one invoice entry, one receipt per tender, one application entry per tender	TestSplitTenderSalePostsEveryEntryInTheSaleTransaction
The till's expected cash equals the session's cash payments (net of change) plus the float less cash refunds; change never subtracted twice	TestTillExpectedCashIncludesFloatAndRefunds, TestChangeIsNeverSubtractedTwice
A void of a card tender sale refunds through the gateway and leaves the ledger at zero	TestVoidOfACardSaleLeavesTheLedgerAtZero
A return restocks and reverses COGS	TestReturnRestocksAndReversesCOGS
The offline sync completes each sale through the same path	TestOfflineSyncPendingOnTaxFailureCompletesOnRetry (found the sync broken: the completion carried no revision, so no sale ever synced; the golden had pinned the breakage) and the pos_sync golden (synced, duplicate, underpaid)
An offline sale synced while the tax provider fails stays pending and completes on retry, never rejected	TestOfflineSyncPendingOnTaxFailureCompletesOnRetry
Contention: three registers at pool 4 get consecutive invoice numbers, no gap, no deadlock against a walk-in payment	TestThreeRegistersConsecutiveNumbersAgainstAWalkInPayment
Two sales of the last unit: one completes, one refused insufficient_stock	TestTwoSalesOfTheLastUnit
A void racing a return: one wins, the other refused	TestVoidRacingAReturn (found both could win: the return now locks the sale row first and moves its revision)
The migration turns each historic ACCOUNT return into an open credit memo	TestMigration105_POSWireContract (memo carries the return's own entry, no new journal or subledger row; awkward legacy rows, down, up, idempotent; the seeded database leg ran on the container at 104 + seed + 105)
The AR invariants of 9.3 after every act, proved by ledger sums	fixture.assertARInvariants runs after every money test; the split tender test asserts the entry legs (1020/4010/2020/1030/5010, 1010/2200, 2200/1020 per tender)

14.1 inputs proved

• IN-1.1 one lowercase status: TestSaleWireShape (IN-1.1 tag in the source)
• IN-1.2 integer cents, never floats: the tenders, totals and floats across the wire tests; a decimal tender is a 400
• IN-1.3 POS- and RTN- numbers on create and every read: TestSaleWireShape, TestReturnRestocksAndReversesCOGS
• IN-1.4 the list envelope, [] in the bytes: TestSaleListEnvelopeAndFilters
• IN-3.7 every refusal the error envelope with its blocker; the revision precondition: TestErrorEnvelopeAndRevision, and the blocker vocabulary (insufficient_tender, change_from_cash, walk_in_account, card_terminal, card_declined, tax_quote_stale, tax_rate_not_configured, credit_limit, insufficient_stock, session_closed, no_invoice, the 503 on a provider outage) is pinned by the wire tests and the goldens

Beside the tests

• Migration 105 pos_wire_contract + down (the ADR 13 C2-5 steps), CONTRACT-CHANGES rows for every route and behaviour, the pos contract fragment rewritten, make contract green, the api-client regenerated.
• The five pos goldens re-scripted and re-recorded (split tender completion against the 12 percent branch rate, the 428 and stale 409, the strict query refusals, the counter's own events read from the feed, the Z report payload masked); six other goldens re-recorded because the counter's sales now really consume stock and post events, and the harness now sorts a cursor envelope's items as it sorted the legacy data. Stability proven by consecutive runs.
• The desk's POS terminal on the new shapes: cents tenders with a split tender list, the revision carried as If-Match, a return modal, the void with its reason. Playwright walks the split tender sale, the return and the void through the real stack; screenshots in shots/c2-5/.
• The wire bugs the fresh contract, goldens and e2e exposed, all fixed: the typeahead and catalog queried a nonexistent products.is_active (500); a walk-in sale priced through the engine with an empty customer id (500); till/current answered 200 with a null body; fresh sales and empty maps/lists read back null; the split tender's payments read in a random order; the return's parse demanded a product beside the line it named; an unknown line or product reached the insert; the sync never completed a sale; the void and the return could both win.
• The seed repoints REG-01 at the Kelowna branch (migration 027 plus 066 left it on MAIN, which carries no tax rate, and the counter refuses a sale on a branch without one).

Fix round 4 (seventh and eighth review findings)

The refund intent table is the one authority on what a card tender has refunded or may be refunding. Every refund act consults it under the sale row lock (the close: under the session lock) before any gateway call or money move.

• Claim after a committed void or card return never reaches the terminal (zero gateway refunds, counted by the stub gateway): TestACardReturnAfterACommittedVoidNeverReachesTheTerminal, TestAVoidAfterACommittedCardReturnNeverReachesTheTerminal.
• A cash return is refused 409 refund_in_flight while a card intent of the sale is PENDING; the card return claims the figure the lock sees and the money transaction refuses (refund_amount_changed, the intent staying PENDING beside the orphan row) when its restated total differs from the amount the terminal took: TestACashReturnWhile...Refuses, TestTheCardReturnBooksWhatTheGatewayTook.
• The close is refused 409 refund_in_flight while any intent of the session's sales is PENDING: TestTheCloseRefusesWhileAVoidIsParkedAtTheGateway.
• Only a definite refusal status releases a claim; an error with no verdict leaves it PENDING with a pos.refund_outcome_unknown audit row (the gateway interface has no idempotency key parameter): TestATimedOutCardRefundLeavesItsClaimStanding.
• A stranded PENDING claim: the gateway's refund id is written onto it in its own committed write, an index on (state, created_at), and a guarded admin route POST /api/v1/pos/refund-intents/{id}/resolve (finance and owner only, a machine key refused in the route itself, bound or not; PR 83's key allowlist is not merged here). A recorded refund books through the act's own money transaction; no_refund with a reconciliation reference marks the claim FAILED and moves nothing; one audit row names the person, the intent, the outcome and the reason. ADR 0005 paragraph and CONTRACT-CHANGES rows added.
• The card cap and the legacy tax reads now have tests that fail under their negated and plain sum mutants; a partly legacy line completes with the linked return that brings the rest.
• Migration 105: the down refuses (an exception naming the count) while a completed sale holds a kit, component, charge or text line; the backfill pairs product lines only.
• The declined later charge reversal loop, the intents a void leaves DONE, and the void claim's status recheck are tested; every request and every wait in the pos tests now has a deadline, so a stuck contender fails instead of hanging the package.
• The generated api-client types follow the new route.

Fix round 5 (ninth and tenth review findings)

Each finding was red first (a test that fails on the previous head), and every proof gap closes with a mutant that turns its test red.

• Every refund method but the card's own (cash, ACCOUNT and any other) is refused 409 refund_in_flight while a card intent of the sale is PENDING, before the return prices and again under the sale row lock: TestAnAccountReturnWhileACardReturnIsParkedRefuses, TestAnAccountReturnWhileAVoidIsParkedRefuses (both answered 201 before).
• A void resolution accounts for each card tender separately: it books only the resolved tender's refund, and the sale's void completes only when no claim of the sale is PENDING anymore, a declined tender keeping its charge as unapplied credit owed to the customer. On the two card sale where the terminal refunded one card and declined the other, the books move exactly the refunded card: TestAVoidResolutionOfOneTenderOfTwoBooksOnlyThatTender, TestTheStrandedVoidOfTwoTendersResolvesOneTenderAtATime. A partly resolved void refuses every later return of the goods (409 void_refund_recorded): TestAGoodCannotBeReturnedAgainAfterAPartlyResolvedVoid. The refusing alternative was not taken: it deadlocks the shape where every card's refund moved and every claim carries its id.
• The resolve route runs behind the branch middleware (serve mounts it through the branch wall at finance and owner), the claim's sale is read through the caller's branch context on both legs, and the no refund leg takes the same scoped sale row lock: a finance user of another branch finds a missing row and moves nothing: TestTheResolutionStaysInsideTheCallersBranch, TestTheResolutionRouteRunsTheBranchGuardItIsGiven, and the serve wiring legs in TestBranchWall_ServeWiring.
• The claim row is locked inside the resolution's transaction, and every claim state change (Complete, Fail, FailByID) refuses 409 intent_not_pending when it settles no row; a lost replay answers the race whatever stage it loses at. Three concurrent resolutions (two refunds, one no refund) at pool 4 settle the claim once: TestThreeConcurrentResolutionsOfOneClaimSettleItOnce.
• The outcome cannot contradict the claim's own record: a no refund over a claim carrying the terminal's refund id is 409 refund_recorded, a differing id is 409 refund_tx_id_conflict: TestANoRefundOverARecordedRefundIdIsRefused, TestARefundIdThatDiffersFromTheRecordedOneIsRefused.
• Only the terminal's explicit DECLINED releases a claim; a PENDING or ERROR answer with no error leaves it standing with the unknown outcome audit row, for the void and the card return alike: TestANonVerdictStatusLeavesTheCardReturnClaimStanding, TestANonVerdictStatusLeavesTheVoidClaimStanding, with the void's timeout and decline paths proved the same way.
• The round 4 proof gaps: the claim restates the remainder it is asked for and books (1794, never the naive 1795; the stub gateway records the cents of every call), a remainder moved in the parked window refuses refund_amount_changed with the claim standing and the replay refusing the same way, and the void leg's resolution audit row rides its booking's transaction: TestTheCardClaimIsAskedForAndBooksTheRestatedRemainder, TestAMovedRemainderRefusesTheBookingAndKeepsTheClaim, TestTheVoidResolutionsAuditRowRollsBackWithItsBooking. Mutants: the amount changed check, the audit write, the void timeout release, the void decline release, the legacy tax completion and the backfill's invoice side filter each turn exactly the named test red. The restate inside the claim transaction and the money transaction's cap, DoneVoid and held rechecks stay equivalent in any deterministic test (the intent table's own guards answer first in every ordering a test can fix); the money transaction's restate, whose refusal the moved remainder test kills, is the authority.
• The P3s: the resolve writes no orphan row on a refused replay; the close's refusal names the standing claims and the resolve route; the 105 down refuses while any claim is PENDING (dropping the table would release its tender) and counts voided sales beside completed ones, said in both files' notes; the route fragment states the conflict refusals, the branch read and the dev mode empty actor.
• ADR 0005's intent table paragraph and the CONTRACT-CHANGES C2-5r4 rows state the new rules; the merged openapi and the api-client types are regenerated.

Fix round 6 (r12 findings)

Each finding was red first (the new test shown failing against the unfixed code), and the gateway's call counts are asserted in every proof.

• A split void completes whatever order its claims are resolved in (r12 P1-1). The completion (cash and check payments voided, every live card application reversed to unapplied credit, invoice voided, stock back, sale VOIDED, event and audit) is one function both legs of the resolution call, under the same sale and claim locks: the refund leg after its own tender's booking, the no refund leg when its release empties the sale's standing claims beside a void claim that already booked a refund. The drawer's session is held in the no refund leg the same order the refund leg holds it. A void whose every claim settles without a booked refund keeps the sale completable by a fresh void. TestASplitVoidEndsTheSameStateWhateverOrderItsClaimsAreResolved resolves r12's two and three card shapes (M3, M5, M6, M10 with cash) in EVERY order and asserts one identical end state per shape (sale status, 1010, 1020, 2200, the walk-in's balance, stock, the drawer's expected cash and card, the stub gateway's call count); TestAGoodCannotBeReturnedAgainAfterAPartlyResolvedVoid now expects VOIDED and the no refund tender's unapplied credit.
• The resolution holds the sale to the caller's grants, header or not (r12 P1-2). With multi_branch_enabled on and default_branch_required off, a finance user held to branch B sending no X-Branch-Id header read the sale through a repository filter that never fired and settled branch A's claim. The route now holds the claim's sale to the caller's grants through the middleware.BranchGuard serve already passes the document and purchase order handlers (WithBranchGuard on the pos handler, wired in serve and the test fixture), whenever the context carries no branch and the caller is not admin or owner: a sale outside the grants is the same missing row (404, nothing moved) on both legs. TestTheResolutionHoldsTheSaleToTheCallersGrantsWithoutAHeader: both legs, both acts (the return claim and the void claim), a granted finance user resolving with no header, and a later card return and fresh void at the sale's branch proving exactly one terminal call per sale in the end.
• A void race loser is told the race (r12 P3-1): the claim row is locked and read right after the sale lock, before every guard of the booking, so the loser of a same outcome race answers 409 intent_not_pending, never invalid_state_transition (the winner's VOIDED sale). TestTwoConcurrentRefundResolutionsOfAVoidClaimNameTheRace: one 200, one intent_not_pending, the sale VOIDED, one refund row, no gateway call.
• The till report's CARD figure subtracts booked void refunds (r12 P3-2), as the CASH figure does for returns: the figure names the session's still completed sales' card tenders less the card refunds resolutions booked (written straight against the tender's payment), and drops with the tender when the void completes. TestTheTillReportCardFigureSubtractsBookedVoidRefunds (the M10 shape: 400 before, 200 with the refund booked, 0 once the void completes). The CARD entry is written only where the session collected on cards, so a cash only session's report and the close's stored map carry no card figure: TestTheTillReportCarriesNoCardFigureForACashOnlySession.
• ADR 0005's resolve sentences and the CONTRACT-CHANGES C2-5r4 rows state the round's rules (the completion from either leg, the order independence, the branch hold for a context with no branch, the claim read right after the sale row, the CARD figure's net).

Fix round 7 (r11 findings: P2-1 and the P3s)

Every proof reaches its recheck through a stand-in row written in the window between an unlocked read and the lock the act takes (a sale row held FOR NO KEY UPDATE, the refund parked at the terminal, the money transaction parked on the till session row it takes between its two reads of the intent facts, the replay parked on the sale row), and every recheck's mutant turns exactly its named test red. No recheck was deleted: none is unreachable through a write.

• r11 P2-1, the claim's restate: TestTheClaimRestatesItsRemainderUnderTheLockBeforeTheTerminalIsAsked. A remainder moved between the pricing and the claim (an unlinked return line through the real tables): the terminal is asked for the restated 1794, never the naive 1795, the return books and the books tie. The mutant (the claim transaction's restate off) reddens it: the terminal is asked the stale figure, the money transaction refuses refund_amount_changed beside the money that moved.
• r11 P2-1, the money transaction's card cap and held figure: TestACardReturnPastTheBookedRefundsRefusesUnderTheLock (a booked CARD return row in the parked window; 409 exceeds_card_tender, the claim stands PENDING beside its orphan row, nothing booked) and TestAClaimWhoseTableAmountMovedRefusesTheBooking (the claim's own row amount moved in the parked window; 409 refund_in_flight). Each mutant books 201 instead.
• r11 P2-1, the money transaction's tender and pending facts: TestATenderTheVoidRefundedBetweenTheFactsReadsRefusesTheBooking (a void claim of the tender stands DONE between the transaction's two facts reads: 409 tender_refunded) and TestAClaimSettledBetweenTheFactsReadsRefusesWithTheRaceNamed (the claim settles between the reads: 409 intent_not_pending, never the misleading refund_in_flight the later check would answer). The mutants book 201 and answer the wrong code.
• r11 P2-1, the replay's pre-cap facts: TestAReplayWhoseClaimWasWonUnderItAnswersTheRaceNeverTheCaps (a winning resolution's whole footprint, the settled claim and the return rows its booking wrote, lands between the replay's read and its transaction: 409 intent_not_pending before the caps, never the winner's own exceeds_sold) and TestAReplayUnderAVoidRefundedTenderAnswersTheTenderNeverTheCaps (a void DONE claim beside that footprint: 409 tender_refunded, the intent table's authority outranking the figure guards). The mutants answer the caps' code and the wrong race code; a refused replay writes no orphan row and no unknown outcome row but the stranded act's own.
• r11 P3-1: TestThreeConcurrentResolutionsOfASplitVoidsClaimsSettleEachOnce. Three contenders at pool 4 over a stranded two card void's claims (the refunded claim recorded once, the timed out claim fought by a refund and a no refund): exactly one 200 per claim, the loser 409 intent_not_pending, the books move once per settled refund (the booked total read from the claims, because which tender carries the terminal's refund follows the tenders' own order), the void completes exactly once whichever leg empties the claims, and the gateway sees only the void's own two calls. The stacked mutant (the route's read, both legs' in-transaction state checks and both row-count refusals off) reddens it: the fought claim settles twice.
• r11 P3-2 and P3-4: the ADR 0005 resolve paragraph and the CONTRACT-CHANGES C2-5r4 resolve row state the interim state (one tender booked, a sibling PENDING: the booked refund reversed its application, so the invoice is open again for the booked cents and the customer's balance carries them as owed until the last claim resolves and the void completes, the close refusing while a claim of the session is pending, so the interim never slips into a counted drawer) and name a no refund of the last claim as a completing leg explicitly.
• r11 P3-3: refusing the declined tender's credit at the payment apply route is not sound, so the limit is stated in the ADR (unapplied cash on one payment is fungible: a genuine overpayment and a void's reversal mix on the same row, so no refusal can be drawn at the cent level and refusing the row would refuse the overpayment too; the apply rule is the account core's own, per customer, with no origin to read; on the shared walk-in customer the exposure is named: a later walk-in invoice could absorb the credit, the dealer's duty is to refund the card). The way back is proved end to end: TestADeclinedVoidTendersCreditIsPaidBackToItsCard pays the declined card's cents back through the payment's own refund route at the terminal (the fixture wires the payment route's gateway the way serve wires Run Payments), the unapplied falls to zero, nothing is owed and the books tie.
• No route, fragment or generated file changes this round: the merged openapi, the api-client types and the route census are untouched and fresh.

Fix round 8 (the fourteenth review's P1s and P2, the thirteenth review's P3s)

Every behaviour change was red first (the new test shown failing on the previous head a7a612b), the 9.3 ties asserted by ledger sums after every money act, and the stub gateway's call counts asserted in every proof. The three test-only gaps of the thirteenth review cannot be red on a correct head, so each is proved by its mutant (applied alone, the named test red, the source restored, the test green again).

• The write path's row (the fourteenth review's P1-2, a regression the first cut made): a branch scoped request naming a location acted on the branch's row with the most quantity, so a cycle count of one yard overwrote another yard's units and a receipt landed in the largest yard. A named location now reads exactly that row, refused (403 on the stock routes, in process for the receive) when it sits in a branch the caller does not carry, never substituted; a first receipt at a yard of the caller's branch still creates its row; only a request naming no location lets the branch rule pick a row, and it takes the branch's first row by creation, a stated rule, never the largest quantity silently; an unbound request keeps the legacy unassigned row. TestAnAdjustWithANamedLocationActsOnThatLocationRowAlone, TestATransferMovesTheNamedRowsAlone, TestAnActOnALocationOutsideTheCallersBranchIsRefused, TestAReceiptAtAYardWithNoRowCreatesItThere, TestAnAdjustWithNoLocationTakesTheStatedRow, and the purchase order receive through the same read: TestAReceiptLandsInTheNamedYardNotTheBranchsLargestRow (red: the receipt landed in the big yard at the previous head, 103 against 100).
• The claim's own terminal call (the fourteenth review's P1-1): a no refund resolution could settle a claim while its act's refund call was still on the wire, freeing the tender; the terminal then refunded it and a later act refunded the same tender again, and the drawer could close over the open call. Every claim now carries an in flight lease and an answer record (migration 107): the call is bounded, every path it can take stamps the answer (the refund id's committed write, the decline release, the no verdict record, and an abandon stamp for a tender whose call a refusal never reached), and the resolve refuses 409 refund_in_flight on an unanswered claim inside its lease under the claim's row lock; once the lease expires with no answer at all the claim is marked UNKNOWN and settles as recorded. The terminal's refund id is written onto the claim whatever state it is in, a recorded refund that never booked holds the tender against every later act, and the refund booked must be the terminal's own id. Red proofs: TestAResolutionCannotReleaseAClaimWhoseActIsStillAtTheTerminal (the resolve was 200 at the previous head and the terminal refunded the tender twice, 1198 against 599; now one refund, one card return refused, the books tie), TestTheCloseHoldsWhileAVoidsTerminalCallIsOnTheWire (the close was 200 under the open call), TestAnUnansweredClaimBecomesResolvableWhenItsLeaseExpires.
• The interim invoice takes no application (the fourteenth review's P2-1): an application to a split void's interim invoice (the customer's own check through POST /api/v1/payments, another walk-in's declined card credit through POST /api/v1/payments/{id}/applications) left a live row the void's completion could not reverse, stranding the last claim (409 has_applications forever) and the drawer. Every application path now refuses 409 void_claim_pending naming the standing claims, before the amounts are read (the AR core asks the counter through a guard serve wires), so the void always completes and the credit stays on its own payment, payable back to its card. Red proofs: TestTheCustomersOwnReceiptCannotApplyToAnInterimVoidInvoice (the receipt was 201 at the previous head), TestAnotherWalkInCreditCannotApplyToAnInterimVoidInvoice (the apply was 200 and the credit was absorbed; now both sales and the drawer settle, the credit pays back to its card).
• The CARD figure subtracts the session's card returns (the fourteenth review's P3-2), through their credit memos, the join the CASH figure always used: TestTheTillReportCardFigureSubtractsCardReturns (red: 1796 stayed after 1198 of card returns; now 598).
• The Z report's payload is a JSON object again (the fourteenth review's P3-3): the first cut had changed it to a base64 string unnamed in CONTRACT-CHANGES; the fragment declares PosTillReport as before the cut, and the characterization golden stops masking the field, so the frozen report's figures are pinned (red: the re-recorded golden held a base64 string).
• The thirteenth review's P3s, each proved by its mutant: the void that completes only beside a booked refund (TestAVoidWhoseEveryClaimSettlesWithoutARefundKeepsTheSaleCompletable; the gate's mutant voided the sale with no refund anywhere), the card refund SQL's completed sale filter (TestOneSalesBookedRefundDoesNotNetAnotherSalesCardFigure; without the filter another sale's figure lost the voided sale's 200), and the no refund leg's session hold (TestTheNoRefundLegAndTheCloseSerializeOnTheSession; the race settles as a completed void with a counted or refused then retried close, never a deadlock). The leg's session lock comment now states the two legs' actual orders and why they cannot deadlock.
• Left for the principal's ruling (TO-PRINCIPAL 91): the ADR's walk-in credit paragraph and the payback rail (the fourteenth review's P3-1 and the thirteenth's P3-4 and P3-6) are untouched. The rechecks the fourteenth review could not reach through real writes stay as they are, covered by the r11 tests the thirteenth review proved bite.
• Migration 107 refund_intent_in_flight_lease (+ down, both cycled on a scratch database beside the 105 cycle), ADR 0005's resolve and till sentences, CONTRACT-CHANGES C2-5r8 rows for every changed rule, the resolve and payment fragments restate the new refusals, and the api-client types are regenerated.

Fix round 9 (FROM-PRINCIPAL 60's walk-in credit rule, both parts)

Every behaviour change was red first (the new test shown failing on the previous head 92257c9), the 9.3 ties asserted by ledger sums after every money act, and the stub terminal's refund call counts asserted in every proof (the counter terminal and the online gateway counted separately: the fixture wires the payment route's gateway the way serve wires Run Payments, beside the counter's own stub).

• The credit is held to its tender (FROM-PRINCIPAL 60a). A declined void tender's credit sat as unapplied cash on the tender's payment, and the apply route answered 200 for it, so on the shared walk-in customer a later walk-in invoice absorbed an earlier walk-in's declined card credit (the fourteenth review's Area 5 shape). The AR core now asks the counter through a held credit guard serve wires (the origin read from pos_tenders.payment_id, the voided sale and the claim the void released), and while the tender's payment still carries the credit unapplied, every path that applies a payment's unapplied cash (the apply route, a receipt's own applications, the deposit paths, all through the AR core's applyLocked) refuses 409 tender_credit_held naming the origin, the void's sale and its claim, and nothing is written. Red proof: TestADeclinedVoidTendersCreditAppliesToNoInvoice (the apply was 200 at the previous head; now 409, the credit unabsorbed, the invoice open, no live application row, the ties hold).
• The credit's one way back is the counter terminal rail (FROM-PRINCIPAL 60b). The payment refund route answered 201 for the credit through the online gateway, the wrong rail (the thirteenth review's P3-4), and no counter route drove the terminal for it. The payback route POST /api/v1/pos/refund-intents/{id}/payback, a small sibling of the resolve route on its own mount (finance and owner only, a machine key refused in the route itself, the branch wall and the no context hold through the same sale read, audited with one pos.refund_intent.paid_back row in the resolve route's shape), keys on the void's own released claim: only a FAILED void claim of a voided sale whose tender's payment still carries the credit unapplied is paid back, exactly once (a second payback 409 no_held_credit, the terminal never asked again), every guard before the terminal is reached. Its terminal call runs under the claim discipline every terminal refund runs under: migration 110 widens pos_refund_intents.act to payback, the payback opens its own live claim before the call (a concurrent payback 409 refund_in_flight, the in flight lease holding the resolve route and the close), the terminal's refund id lands in its own committed write, and the money transaction books the credit out through the AR core's refund (the credit's unapplied cash falls to zero, the cash account moves by the refund). A terminal decline releases the claim and moves nothing (409 card_refund, the counter may ask again); a no verdict payback settles through the resolve route (its refund leg books under the terminal's own id, its no refund leg releases the claim; the resolve fragment's act enum gains payback). The payment refund route refuses a held credit 409 tender_credit_held before its online gateway is ever asked. Red proofs: TestADeclinedVoidTendersCreditIsPaidBackThroughTheCounterTerminal (the online refund was 201 at the previous head), TestAPaybackWhoseCallAnswersNoVerdictSettlesThroughTheResolveRoute and TestAPaybackTheTerminalDeclinedReleasesItsClaim (the route was a 404 at the previous head), TestThePaybackStaysInsideTheCallersBranch (the wall: another branch's caller 404 with no claim and no terminal call, a granted caller under another branch's header 403, the in branch payback 200), TestAMachineKeyNeverPaysBackAHeldCredit. No golden: the route is new and no seeded characterization data names it.
• ADR 0005's walk-in paragraph states the rule (held to its tender; paid back only through the payback route on the counter rail; until then held), replacing round 7's fungibility argument (the thirteenth review's P3-6); CONTRACT-CHANGES C2-5r9 rows for the held credit refusal, the payback route, the payment refund route refusal and migration 110.
• Migration numbering: this branch's in flight lease migration is renumbered 107 to 109 (git mv both files), so PR 83's 107 and 108 stay free and the two branches merge in either order. Fresh apply through 110, and the 105, 109 and 110 down/up cycles, proved on the round's container.
• The merge of refactor/v1 (35 commits: PR 99's AP and GL changes, PR 107's contract fixes) landed with no conflicts: the merged openapi.yaml and schema.d.ts were regenerated from the fragments and the pinned openapi-typescript and are byte identical to the merge's, and CONTRACT-CHANGES keeps both sides' rows.
• PR 83 has not merged at push time, so the key allowlist section does not apply here: the resolve and payback routes go into it as REFUSED for a branch bound key when PR 83 lands.