Proposal: render-three-class-consent-authorship

The consent surface advertises a three-class trust model — protocol-enforced facts, manifest-authored descriptions, and client-authored claims — and the operator-ui consent card already renders each class distinctly (every element carries a data-authorship provenance hook). But the reference Authorization Server's hosted consent renderer (reference-implementation/server/routes/as-consent-ui-helpers.ts) did not honor that boundary:

The reference Authorization Server's hosted consent UI SHALL render authorization requests in terms of the effective access the owner is approving, not only in terms of request shorthand. A stream wildcard SHALL NOT be rendered as a bare *; the UI SHALL disclose that all streams for the requested source are in scope and SHALL show the resolved stream count and names when the source manifest is available. Long-lived continuous access SHALL receive a distinct risk affordance, especially when no expiry or retention bound is present.