[antoinetoussaint-byte]

A solution page now receives its viewer organization's installation from the host, as an optional SolutionBinding.installationId.

Why

An agent module binds every assistant turn to an (installation, intent) pair that it verifies against the host. The host handed a solution page only solutionId, apiBase and the token accessors, and an org member has no read from (organization, solution) to installation. So a consuming solution could only run that module's assistants by asking a person to paste an installation UUID. That is self-identification, and a page-chosen installation could be another organization's.

The data was already there. SolutionEntitlementService.ListSolutionEntitlements returns installation_id for every entitled installation; the gateway's /solutions/_entitlements projection dropped it. Agreed with the #953 author: resolve it per (viewer organization, routed target), never by alias, never from the page, on main after #953.

What changes

• auth-gateway: solutionEntitlementEntry carries installationId, copied from the authority answer.
• frontend: SolutionEntitlement.installationId is parsed (empty when an older gateway does not say) and is part of the projection cache revision.
• New projection GET /api/solutions/[id]/installation: verified entitlements → the navigation's own entitledSolutions join over the whole registry → {installationId, healthy}, or 404 for unregistered and unentitled alike. Registered in the boundary test's projectionSurfaces, so it must keep narrowing through the entitlement read.
• SolutionOutlet reads it with authedFetch and passes installationId to the remote. Undefined while resolving or on any refusal; it never substitutes a value.
• saas-ui SolutionBinding.installationId?: string, optional per the binding's own rule (a minor of the host↔remote contract).

Classification: fix at the owner (the host decides which installation a viewer acts in). Docs: module/SOLUTION_REGISTRATION.md (§4, the third projection) and services/frontend/code/packages/saas-ui/README.md.

Verified

• auth-gateway: go vet ./... and go test ./... pass; the entitlement test asserts the id travels.
• frontend: tsc --noEmit clean; the solutions, api/solutions and saas-ui solution suites pass (382 tests), including 5 new route tests (entitled, unentitled, unregistered, older gateway, unauthenticated) and 2 outlet tests (the id reaches the page; a refusal hands none).
• module/tools (boundary and doc-claim gates) passes.

Not verified

• No composed run. Locally a host still holds no installation until an org admin installs the solution: after feat: the solution and module lifecycle — a static delivered half and a dynamic runtime half (#952) #953 that needs a delivered, live target (ListAvailableSolutions → InstallSolution with target_id), and a local delivery verb is the open question the feat: the solution and module lifecycle — a static delivered half and a dynamic runtime half (#952) #953 author offered to raise.
• An org member who holds no solution:use grant gets no installation: the entitlement read returns only granted installations, which is the intended narrowing.

🤖 Generated with Claude Code