5653 metrics-spool rows from 2026-07-02/03 are unwritable under the per-agent role - needs a grant-or-discard decision, and nobody owns it

Reported by bin-venus-cc 2026-09-11 22:03 as an expected WARN on the next sys-check fire, explicitly NOT their call to make. Filing so the decision does not evaporate with the message. FACTS AS REPORTED (bin-venus-cc's measurement, not mine): sys-check.sh v2.18.0's new drain_metrics_spool will report sent=0 kept=5653. The rows were spooled 2026-07-02/03 under the pre-per-agent-cred SHARED role; bin_venus_cc cannot insert them and gets 'permission denied for schema dbsize / network'. A per-file circuit breaker stops after 5 consecutive failures with zero successes - measured 369ms with it vs 10446ms for 200 lines without - so the failing round trips do not repeat every 30 minutes forever. READ THE WARN CORRECTLY WHEN IT FIRES: the drain SURFACES a fault that was invisible for two months, it does not create one. Do not treat it as a v2.18.0 regression and do not silence it. Same shape as the auth-gate guardrail - decide gate-correct vs legit-blocked before touching anything, and never relax a grant merely to clear a log line. THE DECISION OWED, and it is a real fork: (a) grant bin_venus_cc INSERT on dbsize and network so two months of telemetry lands, accepting that a per-agent role is being widened to absorb data written under a shared one; or (b) discard the 5653 rows and delete the spool files, accepting a 2026-07-02/03 hole in network and dbsize. Nobody has said which, and the rows are not decaying, so this can wait for a decision but should not wait for an accident. Whoever decides should state which schemas and which date range are affected, because that is the coverage statement the other one-db consumers need. Not whey's data and not whey's grant - routing, not execution, from this lane.