feat(licensing): enforcement coverage + GET /capabilities (v0.7 criteria 2 and 3)

[remyluslosius]

Closes the last two v0.7 exit criteria. Both turned out to be buildable without the route mapping I said they were blocked on: seven of the nine paid capabilities have no routes yet, so there was almost nothing to map.

Criterion 2: fail the build when a paid route ships ungated

Checks both directions:

declared -> enforced	a route naming a feature must name a registered one, and enforce it in that route's own call graph
enforced -> declared	a paid feature enforced in the server package must be declared by some route, or the contract hides a paywall

The second direction found a gap I created three PRs ago: the attestation gate from #766 is enforced in the handler and declared nowhere. Fixed here.

It passes almost trivially today. That is the point. It exists so that when bulk remediation lands in v0.9 and someone forgets the gate, the build fails instead of the capability shipping free.

A new annotation, and the distinction is load-bearing

x-required-feature means the whole route is paid. x-conditional-feature means paid for some requests, decided from the body.

Reports are the live case: only the attestation kind is entitled, so a route-level declaration would state in the public contract that a free route is paid. Collapsing the two forces a choice between lying about a free route and leaving a real gate undeclared — and the second is exactly what happened.

Two mistakes in my own first cut

Both caught by negative-testing, not review, and both the same class:

1. The conditional branch searched the whole package for the constant. That passed a route whose gate had been swapped to a different feature, because the right constant still appeared elsewhere. A loose match in a security check is worse than none: it reads as coverage.
2. enforces() hardcoded the auth. prefix. Reusing it for license constants silently reported every license gate as missing.

Negative-tested all three failure modes: unregistered flag, gate swapped to a different feature, gate enforced but undeclared. All three now fail; the middle one is the case that slipped through first time.

Criterion 3: GET /capabilities

Before this, a Community user could not tell a paid tier existed. The only way to discover an entitlement was to click something and collect a 402.

Built entirely from the registry plus the runtime check, so it cannot drift from what is actually gated.

Unauthenticated by design, like GET /license. AC-03 asserts the no-disclosure property against the raw JSON, not a typed struct — a typed decode would silently ignore an added field, which is exactly the leak being guarded against.

No quotas in the response, because there are no quotas in the product. A "78% of your host allowance" indicator would invent a limit that does not exist.

Not done

The lock and upsell UI. The endpoint is the contract the UI needs, but where a lock appears, what the upsell says, and how a grace-period banner reads are product decisions rather than plumbing. Marked out of scope in the spec so it does not read as finished.

Verification

New spec api-capabilities 1.0.0 registered in specter.yaml; system-license-features 1.1.0 -> 1.2.0. 117 specs, 117 passing. Full go test ./internal/... clean locally before pushing.