Budget refusals carry trip-site and raw-vs-settled diagnostics (LLP 0097)

[platypii]

Remote perf testing after #305 deployed showed the fix working for every WHERE-carrying scan, but unfiltered scanning aggregates (MIN/MAX/COUNT over a column with no WHERE) still refuse on the central server at a near-constant ~3.14GB of post-GC growth. That number cannot be reproduced locally: the same code over the local cache retains under 2MB, and every engine path (scanColumn fast path, streaming accumulators, buffered fallback) was ruled out by probes.

The blocker is that a refusal from a remote daemon carries no evidence. This makes every budget refusal self-diagnosing:

• The error message ends with [site=<check-site> raw=<n>MB gc=confirmed|unavailable baseline=<n>MB], so the diagnosis travels through the MCP error string to the investigating client.
• QueryExecutionBudgetError exposes the same values on .diagnostics.
• The query.execute_sql span records budget_trip_site, budget_raw_mb, budget_settled_mb, budget_gc.

Sites are row_scan, column_chunk, watchdog, and terminal. The raw-vs-settled split distinguishes "the memory was genuinely live" from "no GC handle was available"; the site says which execution phase held it.

LLP 0097 updated in the same commit. npm test and npm run build:types clean.

[platypii]

Reviewed. Clean change, tests pass, LLP anchor valid.

The diagnostics threading is correct. Core invariant holds: settled is always at most raw (GC only frees memory), so the rawBytes >= observedBytes assertion can't spuriously fail, and trip stays idempotent with first-writer-wins. Site labels are all [a-z_]+ so they match the message regex, and the unavailable path correctly reports settled === raw.

Minor note (non-blocking): the new diagnostics reporting code has no @ref of its own, though the behavior is now documented in the LLP 0097 update. Judgment call.

LGTM.