Deploy blockers: tailnet door binds in a service-owned directory; grant-list probe reads its whole listing

[gunbai-bot]

These are the two confirmed blockers for the srv1 `dashboard_deploy` step, found by smart-gull-336's precondition sweep and verified live on srv1 on 2026-10-10. The operator's deploy is waiting on this PR, because all four fleet-converge runs pin one revision R.

1. The tailnet door could not create its socket

• What failed: `gunbc-roadmap-tailnet-door` runs `User=briansrls --unix-socket /opt/gunbc/tailnet-door.sock`. The deploy re-asserts `/opt/gunbc` as `root:root 0755` (`sudo -u briansrls test -w /opt/gunbc` answers no). So the door can't bind, and readiness, which requires the door, can never hold.
• Earliest unjustified boundary: `dashboard_instance_tailnet_door_socket`'s own annotation assumed "the instance root, which the service principal owns". That's false for srv1-live.
• Repair (the same move v1 closeout mega branch #13641 made for the event worktree):
  • The socket now lives in `<instance_root>/tailnet-door/door.sock`.
  • The directory is an owned-directory target (`dashboard_instance_tailnet_door_directory`). `gunbc.live_deploy.spec` `deployment_spec_for` appends it through `deployment_tailnet_door_directories`, but only for a deployment whose serve route targets a unix socket.
  • The one directory provider ensures it and reads it back before the unit binds.
  • It's a deployment demand, not an instance one: lab instances route to a port. The `dashboard_instance_directories` annotation says so rather than claiming to be the only list.
• Consumers of the socket path, all read through `dashboard_instance_tailnet_door_socket`: the spec's serve backend (`srv1_live_deployment_names`), the door unit (via `deployment_tailnet_door_socket`), `tailnet_door_witness_test`, `tailnet_door_cutover_witness_test` and `workspace_allocation_http_witness_test`. No literal path needed changing.

2. The tailscale grant probe read a present grant as absent

• What failed: `extdeps.sudo` `sudo_nopasswd_grant_list_shell_condition` ended `sudo -n -l | grep -v | sed | sed | grep -Fqx` under `pipefail`. `grep -q` exits at its first match while `sed` is still writing. After tonight's `gunbc-ghrunner` drop-in the listing is ~13 KB, so the writer takes SIGPIPE and the pipeline exits 141 (20/20 runs as ghrunner).
• Repair: the last stage is `grep -Fx -- >/dev/null`. It consumes the whole listing and still answers by exit status.
• Neighbours swept: no other `grep -q` ends a pipeline. `extdeps.tools.grep` reads a file path.

Evidence

`gunbc test` on srv1 at this head: results to follow as a comment (deploy_mutation_gate, live_deploy/emit, deploy_access_privilege, tailnet_door, tailnet_door_cutover, workspace_allocation_http, desired_roster, member_identity).

Not executed here: the wet door bind and the readiness readback. Those are the deploy itself.

🤖 Generated with Claude Code