htpasswd.entry does not observe the mode its apply sets

[haribo]

Part of #634.

htpasswd.entry's apply ends with:

mv -f "$staged" "$path"
# A credentials file readable by anyone is the credential leaked.
chmod 600 "$path"

Its observe returns a single field — whether the stored hash verifies against the password.
A file with the right hash at mode 644 is therefore reported already, and the chmod
never runs. The def's own comment says what that costs.

sudo.write and sshd.config, the two defs built like it, each observe a secured field
beside their content field. This one does not.

Build

Add the mode to the observe, as its neighbours do — state(valid: …, secured: …). Their
spelling is [ "$(stat -c '%a' "$f")" = "600" ]; file.mode uses an awk numeric compare
for a reason worth reading before copying either (#543).

Validation

• An adverse case: a correct file chmod'd 644 on purpose, then the def, then assert the
  mode on the machine. Verified red before the fix.
• The existing adverse-htpasswd.entry.shellf and adverse-htpasswd.regex-login.shellf
  stay green — neither asserts the mode today, which is how this survived.

[haribo]

Audit against the current code

Central claim: confirmed.

• internal/std/htpasswd/entry.shellf:56-58 — the apply ends mv -f "$staged" "$path", then
  the comment "A credentials file readable by anyone is the credential leaked.", then
  chmod 600 "$path".
• internal/std/htpasswd/entry.shellf:27-41 — the observe returns exactly one field,
  valid: the stored hash is re-derived with its own salt and compared. Nothing reads a mode.
• Consequence, from internal/lang/eval.go:471-489: valid has no same-named parameter, so
  it is an assertion that must be truthy. A file holding the right hash at mode 644 makes it
  true, the def converges, and the chmod never runs.
• The two defs shaped like it do observe a mode: internal/std/sudo/sudo.shellf:24 and
  internal/std/sshd/sshd.shellf:18, both secured: [ "$(stat -c '%a' "$f" …)" = "…" ].

One claim in this issue is false. It says the two existing adverse cases "neither asserts
the mode today, which is how this survived". test/e2e/plans/adverse-htpasswd.entry.shellf:38
does assert it — [ "$(stat -c '%a' /tmp/adv-htpasswd/users)" = "600" ]. The assertion is
simply unreachable as evidence: line 32 calls the def with a different password, so the
apply runs and chmods on the way. What is missing is a case where the observe converges — right
hash, wrong mode — which is precisely the third adverse kind (adverse-cases.md:53-57).

On the #543 warning. It does not apply here. file.mode (internal/std/file/file.shellf:34)
needs its awk numeric compare because its field is named after a parameter (mode: str) and
must equal the caller's spelling — 640 vs 0640. Here the mode is a constant the def chose, so
the field is a plain assertion and the neighbours' string compare against "600" is correct.

Scope check. test/e2e/plans/coverage.shellf:128 calls the def on a path the apply always
chmods, so the added field converges on the second run; no other caller in the tree.

[haribo]

Delivered in #644, squashed to e30fe0a on develop.

internal/std/htpasswd/entry.shellf now observes state(valid: …, secured: …), the shape
sudo.write and sshd.config already had. The apply is untouched.

test/e2e/plans/adverse-htpasswd.entry-mode.shellf is the case, verified red on a real
container before the fix:

RED   htpasswd.entry(path=…, user=covadmin, password=hunter2) ok.already   → file still 644
green htpasswd.entry(path=…, user=covadmin, password=hunter2) ok.set       → 600, hash still verifies

Then twice over: ok.set / ok.already, 600 /tmp/conv634/users. Green in CI's e2e job.