fix(docker): restore seaweedfs-init fail-fast, interpolate its bucket

[nhobin219]

Fixes both review findings on #38, which were raised after it merged.

1. required: false deleted CHA-542's fail-fast (Medium)

required: false is not scoped to "the dependency is absent." It equally downgrades a dependency that is present but exited non-zero. Measured against a dependency that exits 1:

Config	Behaviour
required: false (as merged in #38)	warning, dependents start anyway, compose exit 0
no required: false	error, dependents do not start, compose exit 1

So in compose.yml it removed the fail-fast that seaweedfs-init's s3.bucket.list assertion exists to provide for the dev and test profiles. A failed bucket create would let the servicers boot against a nonexistent bucket and surface later as opaque NoSuchBucket errors — exactly what that assertion was written to prevent.

#38 verified the flag on the success path (waits) and the absent path (starts clean), but never the failure path, and shipped a comment asserting the failure path was still a hard gate.

It cannot just be dropped. With the seaweedfs profile off the service isn't in the project, and compose rejects the whole thing:

service "query" depends on undefined service "seaweedfs-init": invalid compose project

Fix: move the relaxation into docker/compose.s3.yml, layered in by penca-up only for the s3 profile. The safe behaviour becomes the default and the relaxation is opt-in, scoped to the one profile that genuinely cannot have the dependency. dev, test, and any raw docker compose -f docker/compose.yml invocation keep the hard gate.

Verified depends_on merges per key, so the fragment relaxes seaweedfs-init while postgres, bootstrap-init and write's lifecycle dependency are untouched.

2. seaweedfs-init hardcoded the bucket name (Medium)

The init job still did s3.bucket.create -name penca and asserted $1 == "penca" while the servicers had moved to ${OBJECT_STORAGE_BUCKET:-penca}. Set that variable with the seaweedfs profile on — or leak it as a shell export, which outranks --env-file for interpolation — and the gateway creates one bucket while the servicers open another. That divergence reads as an empty table rather than an error, the same failure mode the anchor was introduced to eliminate.

Fix: interpolate the same variable in both the create and the awk assertion.

Testing

Check	Result
Full integration suite, fresh stack	726 passed, 16 skipped, 0 failed (66 serial + 660 parallel)
just lint / format-check / static-test	pass (214 static)
just cargo-check	pass
dev profile	seaweedfs-init back to required: true
Custom bucket	s3.bucket.create -name renamed-bucket + matching assertion
awk $1 survives interpolation	exit 0 when bucket present, 1 when missing
s3 profile	starts with no SeaweedFS; full write → persist → cold-read → DML round trip against a real bucket

No didn't complete successfully warnings anywhere in the suite log, confirming the restored dependency is satisfied rather than downgraded.

🤖 Generated with Claude Code