fix(config): bind SP_ENCRYPTION_MASTER_KEY so credentials stop being stored in plaintext

[fclairamb]

The bug

SP_ENCRYPTION_MASTER_KEY never bound anything. koanf's env provider lowercases
the name and turns every underscore after SP_ into a dot, so it arrived as
encryption.master.key while the tag is master_key. The credentials service
therefore stayed in disabled mode and stored secrets in plaintext — while
logging a remediation message naming the exact variable that does not work:

WARN credentials encryption disabled — secrets stored in plaintext
     how_to_fix="set SP_ENCRYPTION_MASTER_KEY (or SP_ENCRYPTION_MASTER_KEY_FILE)"
WARN Unrecognized SP_* environment variable is ignored  name=SP_ENCRYPTION_MASTER_KEY

Both lines, same boot, in production. The warning was right and the advice it
contradicted was not.

This is not a new class of problem — it is project_koanf_env_quirk, and every
other multi-word key already has a hand-written helper: applyACMEEnv,
applyRateLimitingEnv, applyPostHogEnv, applyWhatsAppEnv,
applySchedulingEnv, applyEntitlementsEnv. Encryption is the one that never
got written, and it is the one where the failure mode is silent plaintext
storage rather than a knob that stays at its default.

The fix

applyEncryptionEnv for SP_ENCRYPTION_MASTER_KEY,
SP_ENCRYPTION_MASTER_KEY_FILE and SP_ENCRYPTION_AUTO_MIGRATE, called next to
applyACMEEnv, with the three names registered in manualReaderEnvVars so the
startup check stops reporting a variable that now binds.

Three inverted assertions, and why they are not being silenced

TestRecognizedEnvVars and TestCheckEnvironEncryptionMasterKeyWarns both
asserted these names were not recognized, and both carried a comment saying
that registering them would paper over the bug. That was exactly right while the
binding was broken. The binding is fixed here, so recognition now states a fact
instead of hiding one — the assertions are inverted with that reasoning written
into them, not deleted. envcheck's package doc, which used
SP_ENCRYPTION_MASTER_KEY as its standing example of a documented-but-unbound
name, is updated for the same reason.

Operational note for the hosted deployment

AutoMigrate defaults to true, so supplying a key also sweeps rows still in
plaintext at the next start.

Rows encrypted under a key that is no longer available stay unreadable — a
different key cannot recover them. solidping-prod currently reports
encrypted rows present ... checks=4, and no key exists for them anywhere, so
those four checks will need their credentials re-entered by hand. A prod KEK is
already generated and waiting at gopass k8xp/solidping-prod/encryption/master-key;
it starts working the moment this ships.

Test

• TestLoadBindsEncryptionMasterKey goes through Load, the path production
  takes. Verified it fails without the fix (expected: "dGVzdC..." actual: "").
• Unit coverage for all three variables, plus the unset case pinned explicitly so
  it cannot inherit the ambient environment.
• go test ./internal/config/... ./internal/envcheck/... green, golangci-lint
  0 issues, gofmt clean.

🤖 Generated with Claude Code