encrypt-container-secrets: state the verbatim key mapping; make A-3 hash-based - #31

…3 could not pass

Both defects in #26, found while implementing v0.2.1 for real.

## 1. The verbatim key-name mapping was undocumented

`modules/env-secrets.md` said the container "hands the values to the
application as environment variables" without ever saying that
`sops exec-env` injects each store key **verbatim** — the key name *is*
the variable name, with no mapping layer and no rename.

That is exactly the case a migration breaks. A value that compose used to
map (`environment: AUTH_PASSWORD: ${MOUSEHOLE_PASS}`) keeps its store key
`MOUSEHOLE_PASS`, the container starts, and the application crash-loops
with "authentication is not configured" because it reads `AUTH_PASSWORD`.
Nothing in the boot path errors, which is what makes it expensive.

Nothing caught it either: the Phase 7 environment check counted matching
environment lines, and a wrongly-named variable simply does not appear in
that count.

Now:

- `modules/env-secrets.md` opens with the rule and a concrete
  before/after (compose mapping → store key), the failure symptom, and the
  remedy under Failure Behavior.
- `SCHEMATIC.md` carries the rule as a Preservation List constraint
  (pitfalls) and as a dotenv-store contract point.
- Phase 7 step 2 compares **names** instead of counting lines: the store's
  keys (decrypted host-side, `sops_` metadata filtered), the application
  process's environment names (found by the `SOPS_AGE_KEY_FILE` marker the
  wrapper exports, not by a guessed PID), and the names the application
  reads. A `MISSING <name>` is the misnamed-key signature, and the Phase 7
  failure modes now list it first.
- Q-2's default names that marker-based discovery.

## 2. A-3 could not pass as written

```sh
docker exec <service> sh -c 'grep -rl AGE-SECRET-KEY-1 / 2>/dev/null'
```

It matches the dedicated key file that is *supposed* to be mounted, so the
expected result was ambiguous, and it walks `/proc`, where it does not
terminate inside a container.

A-3 is now a content-hash procedure: the mounted key is identified by
sha256 against the host's dedicated key (must match) and against the
master key (must not), and the master key's bytes are searched for by
digest over the container's own filesystems — `/proc`, `/sys` and `/dev`
pruned, `-size` filtered before anything is hashed.

The same unbounded pattern was swept out of Phase 7 step 4 and A-4: both
are now scoped to the writable locations, with `docker diff` alongside so
a write outside the scanned directories is still visible.

`version: 0.2.1 → 0.2.2`, `updated: 2026-09-17`, and a Decisions entry
recording both fixes.

Refs #26

…hat produced them

The Decisions entry narrated two defects and cited the issue that tracked them,
and the A-3 provenance paragraph told the story of the test it replaced. Both now
state what is true: the store key name is the variable name, and A-3 decides by
content hash rather than by a substring that also matches the key which is
supposed to be mounted.

Everything a builder needs is kept — the traps (a count of environment lines
cannot see a wrongly-named variable; a substring scan matches the mounted key and
descends into /proc, where it does not terminate) and the verification provenance
(verified in alpine:3: 0 with no copy present, 0 for a same-size file with
different content, 1 when a copy is planted, each under a second).

Prose only: no command, threshold, order, or check logic changed.