A confined capability's ceiling should be the modules its consumer declares it consumes, not the installation's audience list #1083

Today (from #1019)

A resource-confined bearer (an MCP client's token for one installed consumer) may mint at StartTask, and the mint is held to a ceiling read from the consumer's installation: allowed_audiences and allowed_scopes. Because both are optional and the install form leaves them empty, #1019 makes an empty ceiling mean nothing for a confined mint (refused by name, naming the field), while an unconfined mint keeps empty-means-unrestricted.

That is fail-closed, but the authority is an admin's hand-maintained list, which can drift from what the consumer actually needs: too narrow breaks the consumer, too wide lets its token mint for modules it never uses.

What the ceiling should be

The modules the consumer solution declares it consumes. This host cannot answer that today:

• the delivered presence document carries module pins (ModulePin{Module, Package, Version});
• a capability's audience is the consumed module's route alias;
• nothing stored joins the two, and the applied document is kept only as text.

Mapping a pin to an alias here would be a guess at exactly the question the ceiling answers.

Done when

• The delivered declaration carries the consumption in the terms the mint checks (the consumed module's audience/alias and the scopes it needs) — a change on the delivery side, which this host then stores structurally.
• A confined mint's ceiling is derived from that record; the installation's lists, if kept, can only narrow it.
• Tests: a confined mint for an audience the consumer does not declare is refused even when the installation's lists are empty or wider.

Follows #1019.