bench: --bucket is the one S3 setting with no env fallback

[jghoman]

Every other S3 setting in bench/src/hoglake_bench/cli.py reads from the environment:

p.add_argument("--s3-endpoint",   default=os.environ.get("HOGLAKE_S3_ENDPOINT", "http://localhost:9000"))
p.add_argument("--s3-access-key", default=os.environ.get("HOGLAKE_S3_ACCESS_KEY", "hoglake"))
p.add_argument("--s3-secret-key", default=os.environ.get("HOGLAKE_S3_SECRET_KEY", "hoglake123"))
p.add_argument("--bucket",        default="hoglake-bench")          # cli.py:104

hoglake-bench is the local MinIO bucket name, so in the bench pod — where the other four are set as env and deliberately emptied for the ambient credential chain — this one still points at a bucket that does not exist in AWS. The result is that every in-pod command carries --bucket posthog-gigahog-mw-dev by hand, on a pod that already knows which environment it is in.

Fix

Give it the same treatment as its siblings:

p.add_argument("--bucket", default=os.environ.get("HOGLAKE_BUCKET", "hoglake-bench"))

and set HOGLAKE_BUCKET in bench/deploy/bench-pod.yaml alongside the existing HOGLAKE_S3_* block, so in-pod runs become hoglake-bench analytics-lifecycle --scale 4 --rows-per-load 1000000.

Not a server concern

Worth recording so nobody goes looking: the server cannot supply a default. CreateCatalogRequestDto(name, dataPath) requires a non-nullable dataPath, and the server config has no bucket or data-path setting. In a footer-shipping design the client uploads the objects, so the client chooses where they live and the catalog only records it. There is no server-side default to inherit — the gap is purely that bench does not read its own environment.

Severity

Low: since #110, bench no longer creates buckets against real AWS, so a wrong or unset bucket fails loudly rather than writing somewhere unintended. This is ergonomics on a tool that is now driven by hand from a pod, not a correctness risk.