Prioritize Basic faction prototypes and connect three missing rule paths

docs/RICHESE_AUCTION_RULES.md

@@ -66,7 +66,7 @@ For Black Market with ordinary bidding, preserve the ordinary opener progression
 
 These questions cannot be silently represented as settled FAQ compliance:
 
-1. **Canceled compulsory lot and an exhausted cache — count resolved 7 October 2026 by user ruling.** The start-of-round reduction and the permission to prevent the cache auction are both printed, and the cancellation table does not say whether a replacement ordinary lot is restored. The user ruled that when no cache lot can run — the cache is exhausted, or the compulsory cache auction is canceled/prevented — **one ordinary lot is restored**, so the ordinary pool runs its full declared count rather than the cache-reduced count. `requireRicheseDeclarationCache` now accepts an exhausted cache (only a malformed or negative count is rejected), and the `richeseAuction` cancellation branch already restores the reduction before the ordinary pool runs. The Karama **authorization** to cancel the compulsory cache auction itself is still gated in `validateKaramaUse` (`richeseAuction` remains non-cancelable), so that branch is the ruled policy awaiting that separate feature rather than a reachable path.
+1. **Canceled compulsory lot and an exhausted cache — resolved 7 October 2026 by user ruling; connected 8 October.** When no cache lot can run, the ordinary pool retains its full declared count without the cache deduction. Printed Karama can now cancel the declared cache opportunity in Basic or Advanced; Advanced Bene Gesserit conversion retains its separate response. Cancellation leaves every cached card in place and skips both first- and last-position offers. The before-cache count is frozen at declaration, so spending a cancellation card cannot recount live hand capacity, and the independent completed-Black-Market deduction remains. Five direct engine smoke scenarios cover first/last, printed/BG cancellation and countered conversion; no broad suite was run for this change.
 2. **Black Market count wording.** Its specific rule conditions reduction on a sale. The embedded Ixian answer refers more broadly to cards put up for auction. The more specific sale condition supports no reduction for an unsold/canceled Black Market offer. Record that composition explicitly; do not decrement merely on declaration.
 3. **Self-purchase of a Black Market card.** The generic alternative methods include Richese, but Black Market says Richese receives all payments and already owns the card. No retrieved paragraph specifies seller exclusion, a self-payment loop, an Emperor payment, or whether self-retention is a sale reducing the normal pool. Do not borrow the cache self-payment exception without a ruling.
 4. **Ixian advanced Technology on special lots.** I20 p.9 broadly applies before bidding on a card and before Atreides inspection. R2's explicit restriction concerns the _ally's post-purchase replacement_, not Technology. Consequently that FAQ cannot justify disabling Technology on special lots. No retrieved Richese paragraph explains an exchanged cache lot's new public face, or the custody of a substituted Black Market lot if nobody bids. This is a genuine interaction to resolve before certifying the combined implementation.