The dev credentials that hijacked every real AWS call, and 36 GB of caches

The dev credentials that hijacked every real AWS call, and 36 GB of caches Two things about the development machine, both found by trying to use real AWS from this directory. ## `.mise.toml` exported the SeaweedFS key as `AWS_ACCESS_KEY_ID` The comment said it was "also exported unprefixed for the aws CLI, which the compose stack's healthcheck and any manual `aws s3 ls` against the dev endpoint use". The healthcheck part was not true — both healthchecks are `pg_isready` and a `wget` to the master's status endpoint — so the whole justification was one person's convenience at the command line. The cost is that environment credentials outrank `AWS_PROFILE` in every AWS SDK's credential chain. So `damrsdev` silently hijacked *every* real AWS call made from this directory: the CLI, `damd`, `dam-worker`, the SDK inside a test. It presents as `InvalidAccessKeyId` with `AWSAccessKeyId: damrsdev` in the response body, and the first command anybody reaches for to debug it — `aws sts get-caller-identity` — is broken the same way, so the error and the diagnostic agree on a lie. It cost twenty minutes and one confused 403 during the archival work. `mise run s3 -- s3 ls s3://damrs-dev/` replaces it: credentials inline, so the dev bucket stays one command away and a plain `aws` in the same shell still talks to whatever the profile says. The example spells out the service name, because the shorter-looking form fails with "invalid choice: ls" and reads like a broken task rather than a missing word. ## Incremental compilation off `target/debug/incremental` reached 36 GB and filled the disk twice in one session, taking the container runtime down with it both times — which surfaced as `rustc` dying with `No space left on device` mid-suite, an error that looks nothing like its cause. Most of that is not the inner loop. `cargo test --workspace` here builds around 136 separate test binaries, each with its own cache, and the gate runs whole — so those caches are written once and read never. The cost is stated in the file and is real: an edit-then-check loop now recompiles its crate rather than the changed functions. If that becomes the thing that hurts, deleting `.cargo/config.toml` is the whole undo, and a full disk is the more expensive failure.