Accept ADR 0053 and resolve issue 008 — provider contract implemented and proven

ADR 0053 accepted; adds the scope boundary the umami rework surfaced (credential
provisions vs data provisions — analytics' generated siteId return is left to a
separate decision) and records the lab proof. Issue 008 marked resolved: the sdk
harness and the four adapters are reworked, the symmetric seal removed, and
provider-uses-mesh-credential is green.

Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF

04-ISSUES/008-provider-runtime-has-no-seal-key/00-report.md

@@ -1,9 +1,9 @@
 ---
-status: open
+status: resolved
 opened: 2026-09-04
 located-in: [mesh-sdk, mesh-catalog]
-fixed-by:
-amended-design:
+fixed-by: mesh-sdk src/provisioner rework + redis/postgres/minio/umami adapters (ADR 0053)
+amended-design: 0053-a-provider-creates-the-credential-the-mesh-minted.md
 ---
 
 # A provider's provisioner seals with a key the mesh has no way to deliver — and does not need to
@@ -107,10 +107,29 @@ not per-provider surgery, and inherited correctly by every provider after them:
 
 This is proposed as ADR 0053, which defines the corrected provider contract, for ratification.
 
-## Open questions
+## Resolution
 
-- Does anything legitimate still use the symmetric `seal()`/`unseal()` primitive, or does it
-  leave with the provisioner?
-- On withdrawal the mesh drops the consumer from the contributions file; is "remove the login"
-  the whole of teardown for every provider, or does an object store (data left behind) need a
-  policy the contract should name?
+ADR 0053 was accepted and implemented on the branches this issue is fixed by:
+
+- `mesh-sdk` `src/provisioner/index.ts` now reconciles the mesh's `receives` contributions and,
+  per consumer, reads the mesh-minted password from the file the host unsealed, calling the
+  adapter to create the resource under the mesh's login. `$MESH_SEAL_KEY`, the symmetric seal,
+  `writeSealedCredential`, and the `*.grant.json` / `*.credential` files are gone. The symmetric
+  `seal()`/`unseal()` primitive had no other caller and was removed.
+- The four adapters (redis, postgres, minio, umami) were re-pointed at the new contract —
+  `create({ as, password, values })` / `remove({ as })`, returning nothing. minio's client gained
+  a secret-key argument so it sets the mesh's secret rather than generating one.
+- Proven in the mesh-lab: `provider-uses-mesh-credential` is green — redis creates the consumer's
+  login with the password the mesh minted, a client authenticates as that consumer and gets PONG,
+  with no seal key set anywhere.
+
+Two things were carved out deliberately, neither blocking:
+
+- **Data provisions are a separate shape.** umami's `analytics` returns a `siteId` umami
+  *generates*, not a secret the mesh mints, and a contract that returns nothing cannot hand that
+  back. ADR 0053 is scoped to credential provisions and says so; the provider→consumer return
+  path for generated data is left to a separate decision. umami compiles and reconciles under the
+  new harness; only that return is unaddressed, and it never had the seal-key fault.
+- **Teardown beyond "remove the login"** — an object store's leftover data — is each adapter's to
+  name (minio leaves a non-empty bucket for an operator rather than deleting a consumer's data),
+  not the harness's.