e2e: the whole grant for an S3 bucket (skipped — blocked on hq issue 010)

Mirrors the postgres bed for minio: a provider (runtime carries mc) + a consumer
requiring s3-bucket, proving the consumer reaches its bucket with the access key and
secret the mesh delivered. It surfaced a real limit: the mesh derives `as` =
mesh_<node>_<module> (22 chars), and an S3 access key is capped at 20, so minio refuses
the service account. The test is correct and skipped pending 04-ISSUES/010, not worked
around.

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

scenarios/minio-node.yml

@@ -0,0 +1,32 @@
+# One machine that becomes a mesh and grants a consumer an S3 bucket from an assigned minio provider.
+#
+# The postgres bed proves the provider/consumer contract for a database; this proves it for object
+# storage (novox/hq ADR 0052/0053), on a provider whose code drives the `mc` CLI (so the runtime image
+# carries it): minio is assigned, a consumer that requires s3-bucket is assigned, and the mesh mints
+# one secret key; minio's provisioner creates a bucket and a service account under the access key the
+# mesh derived with the secret it minted, and the consumer reaches its bucket with only that.
+scenario: minio-node
+
+segments:
+  hosting:
+    kind: public
+    cidr: [192.0.2.0/24]
+
+machines:
+  anchor:
+    at: { segment: hosting, address: [192.0.2.10] }
+    inbound: allow
+    memory: 3GiB
+    cpus: 2
+
+images:
+  - postgres:17-alpine
+  - cloudamqp/lavinmq:latest
+  - mesh-control:development
+  - minio/minio:latest
+  # minio's runtime, built by scripts/build-module-runtime.sh minio (it carries mc), stocked into the
+  # scenario's own registry.
+  - mesh-runtime-minio:development
+
+place:
+  all: [host, runtime]