Install-time trust model: distro-blessed vs permission-required manual installs (blocked on signing) #995

Summary

Follow-up from #991 (item 4). The install path currently accepts a capsule manifest's declared capabilities regardless of source — there is no blessing or install-source trust distinction in code.

Intended model

• Capsules delivered as part of a distro are blessed: their declared tools and capabilities are accepted because the distro vouches for the whole set (zero onboarding friction).
• A capsule added outside a distro (manual install) requires explicit permission/approval before its declared capabilities take effect.

Blocker: needs a cryptographic trust anchor

"Blessed" must be verifiable or it becomes an approval-bypass primitive: the instant a blessed set is exempt from the approval / elicitation gate, an unsigned blessed manifest is the way to skip approval. This requires a signed distro manifest the kernel verifies before honoring the exemption. No release signing exists today (trust = GitHub + TLS), and the signing decision is currently deferred. This item is blocked until release / distro signing is decided and implemented.

Coordinate with

• The MCP elicitation / consent gate (the gate for everything outside the blessed set): the blessed-set check should be a single source of truth the elicitation contract consults, not a hardcoded trust list.
• The blessed manifest can double as the load-time tool registry (a known expected set for the cold-start fan-out).

Refs #991.