fix(seller): reserve a share of each cycle for items without a price override

[icemansparks]

Follow-up to the caveat I flagged in #36.

The bug

GetItemsToSell() returns four blocks concatenated:

1. price override items below their target count
2. every sellable price override item
3. bin items not currently in the auction house
4. bin items (currently dead code — the append is commented out)

Sell() then walks itemsToSell[cnt] for cnt in 0 .. ItemsPerCycle-1 — always the first 200 entries. Blocks 1 and 2 hold thousands of entries on this realm (~11.5k override rows), so index 200 never reaches block 3.

Consequence: an item with no row in mod_auctionhousebot_priceOverride is never listed, no matter how cleanly it passes every filter. That is not a deliberate priority ordering, it is starvation — prioritisation by concatenation against a fixed per-cycle budget.

It also undercuts #36: un-blacklisting the Shredder pages makes them eligible but not visible, unless they happen to carry override rows.

Fix

The two sources are collected separately and woven, so that over any stretch of the list AuctionHouseBot.BinItemShare percent of the slots belong to bin-only items:

credit += share;
if (credit >= 100 && nextBin < binOnlyItems.size()) { credit -= 100; take a bin item; }
else                                                  take a priority item;

Default 25 — a 200-item cycle now lists ~50 items that have no price override, where it previously listed none. 0 restores the old concatenation order exactly.

Prices for those items fall back to the existing C++ path (SellAtMarketPrice / BuyPrice / SellPrice scaled by the per-quality min/max percentages), which is what that code was always there for.

Verification

• Weave logic checked against a standalone harness: ratio held in the first cycle at 10/25/50/100 percent, 0 produces the legacy order with bins strictly after priority items, no items lost, and exhausted-source cases terminate. All assertions pass.
• Full module compile: the core-build workflow on this PR.
• Not yet run on testcore.

Tuning note

25 percent is a starting point, not a measured optimum. The higher it goes, the slower the override-priced items restock; the lower it goes, the longer the tail of unpriced items takes to appear. Worth a look at the TraceSeller line this adds — it logs both candidate counts and the applied share per cycle.