feat(edp): provision Foundry reader grants

infra/deploy-runner/README.md

@@ -182,13 +182,14 @@ force-recreates only `external-data-plane`; the already healthy
 independent deploy prerequisite and are never selected by an EDP application
 artifact. The reviewed Compose source pins the Timescale image, named volume
 and target, internal database-only network, absence of database host ports,
-healthy dependency, localhost-only EDP bind and the two read-only
+healthy dependency, localhost-only EDP bind and the three read-only
 provisioner/trust mounts in the reviewed Compose source. The runner does not
 reinterpret version-dependent `docker compose config` JSON as a second deploy
 schema. Its canonical enforcement remains the artifact/path allowlist plus
 hard-coded build command, selected service set, runtime-secret preparation and
 health acceptance. Post-apply acceptance also requires
-`database=ready`; a first-rollout failure removes only the candidate EDP
+`database=ready`; the managed Foundry slice additionally requires
+`foundryReaderBindingProvisioning=digest+server-resolved-source`. A first-rollout failure removes only the candidate EDP
 container without volumes and restores the source overlay. It never contains a
 provider credential, provider endpoint,
 collection schedule or command
@@ -218,6 +219,21 @@ symlinks and permissive modes fail closed. `plan` discloses both paths without
 printing key material. The private key must not be broadened into an L2 graph,
 MCP surface, artifact or shared-token boundary.
 
+Module Foundry has a separate Ed25519 managed-provisioner identity for
+target-scoped Data Product consumer grants. On a relevant `platform` or
+`module-foundry` apply, the runner creates or validates the Foundry-only private
+key at
+`/volume1/docker/nodedc-platform/secrets/foundry-edp-managed-provisioner/private-key.pem`
+as `root:root 0400` and the matching EDP trust copy at
+`/volume1/docker/nodedc-platform/trust/foundry-managed-provisioner/public-key.pem`
+as `root:11006 0440`. Foundry generates the opaque reader token only inside its
+persistent private runtime; its signed EDP request contains only a SHA-256
+digest and Data Product id. EDP resolves the unique active writer source scope
+server-side and fails closed on missing or ambiguous coverage. No provider,
+tenant, connection, token, private key or endpoint is admitted to the Foundry
+MCP plan, application state or browser response. The Engine signing identity,
+native n8n credentials and legacy issuance bearer cannot call this endpoint.
+
 The reviewed Engine source candidate has dedicated server-derived MCP
 plan/apply handling for the exact `ndcDataProductWriterApi` + Data Product
 Publish tuple. It is separate from the generic HTTP safe-ref path and accepts no
@@ -340,6 +356,12 @@ never enters an artifact. The component reuses the existing internal platform
 credential for Launcher handoff validation and requires that runtime
 configuration before its first `apply`.
 
+When the managed reader-grant source is present, Module Foundry acceptance also
+requires `/healthz` to report the dedicated Ed25519 provisioner as configured.
+The check is source-aware: if an apply rolls back to the prior source, rollback
+acceptance uses that prior health contract instead of falsely requiring a
+feature which the restored generation does not contain.
+
 The Foundry ↔ Map Gateway signing key is not an application or `.env` setting.
 On the first relevant `platform` or `module-foundry` apply, the root-owned
 runner creates `/volume1/docker/nodedc-platform/secrets/map-gateway-admin-secret`