spark serving: observe the managed account and its key-file mode, before authoring any row about it

[gunbai-bot]

Marker #6 of the #8377 spark-serving dissolve-on set. The parent lane's ruling on this one was
explicit and is what shaped the PR: observe first. Authoring fleet_posix_accounts rows from
inference is the exact error that got a module deleted two PRs ago (#8811), so this PR extends the
observation and stops there. The rows are the follow-up, authored from the receipt below and citing
it.

What was unobserved

The 19:19 serving observation had no account field of any kind. Not a partial one -- none. So
every fact a fleet_posix_accounts row would assert was, as of this morning, unmeasured on the
converged hosts.

The four states

SparkManagedAccountObservation is a coproduct, not an Optional:

state	means
ManagedAccountObserved	login, uid, gid, shell, key-file mode, key-file owner
ManagedAccountKeyFileUnread	the account is there; the key file did not read
ManagedAccountAbsent	getent passwd found nothing
ManagedAccountProbeRefused	the leg was never attempted

"The account does not exist" and "we could not read its key file" have different remedies. An
Optional collapses them, and the second one matters more than a missing field: sshd refuses keys
on an over-permissive file, so an account that exists with a world-readable authorized_keys is
non-functional in a way that looks like a present account.

Why ls -ld and not stat -c

Not a style choice. portable_remote_word admits only [A-Za-z0-9._-/@:=,], and % is not in that
set -- no stat format string can ever be a portable word through this transport. I got this
wrong first: I blamed the spaces in %a %U %G and respelled it %a:%U:%G, which was refused
identically. The second refusal is what falsified the first diagnosis; reading the allowlist rather
than pattern-matching the error is what produced the real one.

Symbolic mode is the better carrier here regardless. The property this observation exists to record
is the key file is not group- or world-readable, which -rw------- states directly and 600
states by convention.

Two defects found by making the change

Both were pre-existing, and neither is cosmetic:

• spark_serving_observe_host declared -> SparkServingObservation while returning a
  SparkServingHostObservation. The typechecker accepted the lie.
• spark_serving_observe_ci_with_context carried a second, hand-copied per-host render join.
  Adding the account line to one left the other silently short -- the account line was simply absent
  from the wet receipt while everything typechecked. Fixed by extracting
  spark_serving_host_observation_lines so both read through one authority. Duplicating the
  addition would have been the §3 fork; killing the fork is what the receipt then proved.

Wet receipt (2026-08-21, both converged hosts)

account host=srv5 login=gunbc-automation uid=1001 gid=1001 shell=/bin/bash
        authorized_keys_mode=-rw------- authorized_keys_owner=gunbc-automation
account host=srv6 login=gunbc-automation uid=1001 gid=1001 shell=/bin/bash
        authorized_keys_mode=-rw------- authorized_keys_owner=gunbc-automation

Convergence is unchanged at 2/2 -- both legs are reads (getent passwd, ls -ld); neither
actuates.

Discriminating RED

the_passwd_fields_are_read_at_their_real_positions asserts uid/gid/shell come from their actual
getent column indices. It goes red on any off-by-one in the field split, which is the failure this
parser can plausibly have and the one a shape-only test would pass over.

🤖 Generated with Claude Code