docs: nport-api is deleted from staging

The pre-rename node script (ADR-0049) had sat unrouted since 2026-08-06,
holding dead SubdomainLease / Registry / SourceQuota objects.

Checked before deleting, because deletion destroys those Durable Objects and a
tunnel they still owned would be stranded if nothing else could see it. Nothing
is stranded: `apps/node/src/reconcile.ts` sweeps the *account's* tunnel list
rather than its own records, the `nport-` prefix is what marks them, and both
scripts shared one account. So deleting the Worker turns its leases into
orphans that `nport-node` reaps with the CNAME ownership proof intact
(invariant 8) — the outcome, not a leak.

Also confirmed it existed only on staging; the production account has no such
Worker, so there was no chance of deleting the wrong one.

Verified after: the four remaining Workers are present, `/v1/health` answers,
`/v1/meta` still crosses the service binding, and the site serves.

The OPERATIONS entry keeps the reasoning rather than just recording the
deletion — the next rename will face the same question.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017ND8DWQLFchUayY5xeP6vb

Author: tuanngocptn

docs/OPERATIONS.md

@@ -106,10 +106,14 @@ For a fresh deployment (also the basis of `docs/SELF_HOSTING.md`):
    The registry resolves it on **every** registration, so deleting it delists the node within
    `NODE_DELIST_AFTER_SECONDS` rather than at the next deploy. That is the intended way to withdraw a
    node from the directory.
-8. **`nport-api` on staging is an orphan** — the pre-rename node script (ADR-0049), still deployed,
-   no route, holding dead `SubdomainLease` / `Registry` / `SourceQuota` objects. Safe to delete, and
-   deleting it destroys those Durable Objects, which is why it is a decision rather than a deploy
-   step. Nothing routes to it and nothing reads it.
+8. **`nport-api` was deleted from staging on 2026-08-09**, and the reasoning is worth keeping for
+   the next rename. It was the pre-rename node script (ADR-0049): no route, holding dead
+   `SubdomainLease` / `Registry` / `SourceQuota` objects, which deletion destroys — so it was the
+   operator's call rather than a deploy step. What made it safe is that **reconciliation is
+   account-wide**: `apps/node/src/reconcile.ts` lists the *account's* tunnels and reaps any named
+   `nport-*` with no live lease, so anything the old script left behind falls to `nport-node`'s sweep
+   with the CNAME ownership proof intact (invariant 8). Deleting the Worker turned its leases into
+   orphans that the surviving one cleans up, which is the outcome, not a leak.
 9. Zone rate-limiting rule on `api.<domain>` — `infra/terraform` applies it: 600 requests / 60 s per IP per colo, blocked for 10 minutes. Deliberately well above the **gateway's** own 60/min per-source limiter, which it sits outside rather than replaces. The node and the registry have no limiter of their own; applying one twice would charge a caller against two counters for one request.
 8. Verify `api` and the rest of the reserved list cannot be claimed.
 

docs/ROADMAP.md

@@ -1385,12 +1385,16 @@ what `nodeProofRecordName`/`nodeProofRecordValue` produce, and every environment
 to serve because it could not get itself listed — trades a working tunnel for a tidy directory. What was
 missing was not an exception; it was a record nothing created, and now something does.
 
-**One thing the deploy left behind.** Renaming the Worker did not delete the old one: `nport-api` is
-still deployed on the staging account with its Durable Objects, and Cloudflare reassigned
-`api.nport.online` to `nport-gateway` without complaint — so the concern that the rename would collide
-on the custom domain did not materialise. What remains is an unrouted script holding dead lease state.
-Deleting it also deletes those DOs, which is fine here and is **the operator's call, not a deploy
-step**: `docs/OPERATIONS.md` § Inventory is where it belongs, and nothing depends on it in the meantime.
+**One thing the deploy left behind, now cleared.** Renaming the Worker did not delete the old one:
+`nport-api` stayed on the staging account with its Durable Objects, while Cloudflare reassigned
+`api.nport.online` to `nport-gateway` without complaint — so the feared custom-domain collision never
+materialised. **Deleted 2026-08-09** on the operator's instruction, after checking the one thing that
+made it a decision rather than a deploy step: deletion destroys those DOs, and any tunnel they still
+owned would be stranded if nothing else could see it. Nothing is stranded, because
+`apps/node/src/reconcile.ts` sweeps the **account's** tunnel list rather than its own records — the
+`nport-` prefix is what marks them, both scripts shared one account, and an orphan with no live lease
+is exactly what that sweep exists to remove. Verified after: the four remaining Workers are present,
+`/v1/health` answers, and `/v1/meta` still crosses the service binding.
 
 **Still not proved: failover.** G5 wants a *second* node on a second account and domain, with a client
 moving to it when the first stops mid-run. One node in the directory cannot demonstrate that, and