RE: Roller by Vash 0.9.7 - Batch performance diagnostics

WHAT CHANGED
The default queue now uses a complete fresh initial build read, then freezes
the selected queue and displayed lists until the batch finishes. It does not
perform full build reads between each roll. A normal six-roll queue makes two
full reads total: one at startup and one after the final native presentation.
Stale final client data can require bounded retries without resending a roll.

Each request still waits for its result event, exactly one matching scroll
consumed, and native presentation completion. Only one request is in flight.
Selected original IDs are fixed; new replacements are never requeued.

SAFETY TRADE-OFF
The whole build is compared at the end rather than before every request.
Do not manually change talents/abilities, switch specs, or use another reroll
tool during a batch. Combat, death, spec changes, errors, protected actions,
unexpected scroll changes and ambiguous results stop further requests.
Stop/Pause continue observing one outstanding request. History is committed
only after full final verification; failed verification is reported for review.
The initial and final native reads may still hitch. No live FPS gain is claimed.

/rr batch off restores the old complete per-roll pre-request/result checks.
/rr batch on restores batching (default). These changes are saved and only
accepted while idle. Neither command sends a reroll.

TEST
1. Back up GrimfallReroll saved variables with WoW closed before installing:
   0.9.7 retains only 20 ability + 20 talent rolls per character.
2. Install only GrimfallReroll. Open /rr and wait for the initial display read.
   /rr perf must report version 0.9.7. Confirm your locks and skin preference.
3. Run /rr perf reset while idle, then /rr batch on.
4. Only if you already intend to spend those scrolls, select the intended
   entries and run one batch. Do not spend scrolls just to produce diagnostics.
   The ability/talent lists should stay fixed until the batch finishes.
5. After final verification, send /rr perf AND /rr pace. Include the status
   message and whether any hitch occurred at startup, between rolls or at end.
6. With no intervening Refresh, a normal six-roll run should show:
   - Batch mode: 1 batch started
   - Queue pre-request read work: 1 call
   - Batch final build-read work: 1 call
   - Batch acknowledgement: 6 calls
   - No per-roll Queue result-read work
   The initial/final reads total two. Extra final reads mean the client was
   not ready to publish a verified final build; they do not resend a reroll.
7. If it stops, do not force another request. Send the status plus /rr pace.
   For the old verification behavior, use /rr batch off while idle.
8. /rr perf reset resets counters, not history or locks. /rr perf prints the
   report in chat. The command is PERF, not PREF.

READING THE REPORT
Batch acknowledgement means event + exact scroll delta + native presentation
completion, not a full per-roll build scan. The final read verifies all results.
Batch gap is acknowledgement to next request; it includes the 100 ms minimum,
scheduling and any pause. It is not pure network or server time.
Batch controls-only render measures status/buttons without repainting lists.
Stages include API work: never add them together. Frame gaps include other
addons and the game. Slow native API calls cannot be split or interrupted.

VALIDATION
243 offline checks and seven Lua 5.1 module compilation checks pass. Tests
cover both six-roll paths, real mocked event-loop scheduling, no extra idle
refresh, pause/stop/late results, blocked actions, timeouts, ambiguous events,
inventory checks, final reconciliation, lock inheritance, history retention,
both skins and the retained per-roll mode. These are not live benchmarks.
No native presentation callbacks are bypassed or invoked directly.

GitHub is unchanged unless publication is explicitly requested. BSM, Postal,
Auctionator and game settings are not part of this package.
