Prove a bucket is provisioned the way a database is

Seven assertions against a real store, the important one being that a
consumer cannot reach another consumer's bucket — isolation here is a
policy somebody wrote rather than a boundary the product has.

The revocation test stages its own precondition. The first version
asserted a key left by an earlier test, and the rotation test had
already revoked it two tests early: the behaviour was correct and the
test was measuring residue. Its precondition assertion is what caught
that, rather than it passing green having verified nothing.

scenarios/an-object-store.yml

@@ -0,0 +1,31 @@
+# One machine running an object store that other machines use.
+#
+# The same shape as `a-provider`, against a different kind of provision, and that is the whole
+# reason it exists: novox/hq 04-ISSUES and the work breakdown's Phase 1.1 ask whether a module can
+# be given a bucket the way it is given a database. The provisioning model is name-agnostic — the
+# control plane special-cases neither — so what is unproven is not the mesh's half but the last
+# step, where something on the machine turns a delivered secret into a key that works.
+#
+# It also proves the half a database does not: **a consumer must not be able to reach another
+# consumer's bucket.** One store holds everybody's, where one PostgreSQL server holds separate
+# databases, so isolation here is a policy somebody wrote rather than a boundary the product has.
+scenario: an-object-store
+
+segments:
+  hosting:
+    kind: public
+    cidr: [192.0.2.0/24]
+
+machines:
+  anchor:
+    at: { segment: hosting, address: [192.0.2.10] }
+    inbound: allow
+
+images:
+  - minio/minio:RELEASE.2025-09-07T16-13-09Z
+  # The vendor's client, stocked so the provisioner has the thing it drives without reaching a
+  # public registry from a documentation range.
+  - minio/mc:RELEASE.2025-08-13T08-35-41Z
+
+place:
+  all: [runtime]