fix(codex): resolve the app-server from the port file when the variable is absent

[fujibee]

#583 seats a codex role from the app-server's loaded threads instead of scanning rollout files. On a real machine it has never run.

Reported with the mechanism attached on #567: the spawned agent does execute the seeding step — the rollout shows the call, the right workdir and exit 0 — and still nothing is recorded.

Why it never ran

The probe was gated on AGMSG_CODEX_BRIDGE_APP_SERVER:

if [ -z "$thread" ] && [ -n "${AGMSG_CODEX_BRIDGE_APP_SERVER:-}" ]; then

Under codex 0.146 --remote, an agent's shell_command runs inside the app-server process, not the TUI client. codex-monitor.sh cannot export into that context: the URL does not exist until the server's banner has been parsed, which is after the server is already running. CODEX_THREAD_ID is absent on this path too (0.141+), so with both missing it fell through to the rollout scan, found the ambiguity #579 is about, and failed closed. Exactly as designed — on a path the design could not reach.

The reporter confirmed the logic itself is right: supplying ws://127.0.0.1:<port> by hand seated the correct thread first try.

The fix reconstructs the value, it does not add a route

codex-monitor.sh is the only writer, and one port produces every form:

:201  printf '%s' "$PORT" > "$PORT_FILE"
:212  SOCKET_URL="ws://127.0.0.1:$PORT"
:217  export AGMSG_CODEX_BRIDGE_APP_SERVER="$SOCKET_URL"
:228  exec "$REAL_CODEX" --remote "$SOCKET_URL"

So the port file and the variable are two carriers of one value. _agmsg_codex_app_server_url prefers the variable when present and otherwise rebuilds the identical string from the file. It cannot produce an endpoint the variable would not have named, which is what makes this safe to ship in a release: no new connection target exists.

A port file that is missing, empty or not all digits yields nothing, and nothing still means could not ask — never asked and found nothing. The probe_ran distinction #583 was reviewed for is untouched, so an unreachable app-server still cannot let the rollout scan overrule a probe.

Second fix in the same report

delivery.sh status told correctly-unseated roles:

has no session recorded, though one thread is loaded
That combination is unexpected — the seat is normally written for it.

A loaded thread seats one role. When the only loaded thread already belongs to another role, this role having no seat is the correct state. The count answered "how many threads are loaded", not "how many are unclaimed", and only the second makes a missing seat odd. The probe now keeps the ids it already fetched, and the branch subtracts the seated set — the same subtraction codex-record-session.sh makes — instead of re-asking.

Evidence

Every new test was checked against a mutation that removes the property it names:

mutation	result
port-file derivation removed (today's behaviour)	seats from the port file … fails
digits guard removed	a half-written port file … fails
wording branch reverted	a thread already seated elsewhere … fails

Suites: test_delivery 165, test_codex_resume 32, test_codex_monitor 9, test_codex_bridge 37 — 0 failures.

Scope held back

A new helper carries the resolution, but only the new caller is wired to it. _delivery.sh and _session-start.sh keep their own resolution in this PR — this is a release blocker, and a behaviour-preserving-looking refactor is how a shared assumption gets split by accident.

Left for #579, so the next person does not repeat the survey:

• printf '%s' "$X" | agmsg_sha1 is open-coded in six or more places.
• The port-file path expression is duplicated between codex-monitor.sh:103 and _delivery.sh:102.
• _session-start.sh:135 reads codex-app-server.<hash>.sock, and nothing in the tree writes that path — a reader with no writer.
• The * branch of the same status case has the shape just fixed in the 1 branch: with several loaded threads all already seated, "none identifiable as its session" is true but the suggested remedy (recreate the app-server) is not.
• The loaded − seated subtraction now exists twice: in codex-record-session.sh, where it decides whether a seat may be written, and in _agmsg_codex_unseated_count, where it decides what the diagnostic says. Fixing one alone would make the diagnostic and the decision disagree. Not merged here because doing so reaches into codex-record-session.sh, which is the half of this PR a release is waiting on.