#299 -- UNREAD CALLEES TRACED, LANE WORK RECOVERED. Source and git history only, nothing run.
Two of my earlier statements were wrong and are corrected below rather than quietly dropped.

== 1. THE LANE WORK EXISTS, AND IT IS UNLANDED. THAT RECONCILES BOTH OF US ==

You were right that the code exists; I was looking at main. The W1 product lane is
`feat/304-remote-friction-product`, tip 3e7eaf67, and it is NOT IN MAIN'S ANCESTRY -- 21 commits sit
on it that main does not have. That is why my working-tree grep found nothing: I grepped the tree the
work had not landed in, and then reported an absence.

THE REQUEST-SPECIFIC COMMITS, recovered from the ancestry rather than the tips:

  #299  d5fe86c31f3befc54dfaab713dd32e259a56ed8a
        "feat(roster): attribute standalone endpoint-list waits by stage", 2026-09-11 01:39
        wan.rs, db.rs, registry.rs, cli.rs, roster.rs, wansend.rs, STORAGE.md, traceable-reqs.toml
        377 insertions. Its own message: opt-in, thread-scoped ROSTER_WAIT records over the
        complete-roster path, separating roster reads, REGISTRY OPEN/TUNE/SCHEMA/QUERY WORK, the
        UNLISTED worklist and each presence probe stage rather than summing them; every record names
        its budget type and producer progress on success and failure; an outer observation cutoff is
        recorded AS A CUTOFF, not as producer completion. Output bytes, roster rows and existing
        deadlines unchanged. "Source-only under the execution hold; no run has been measured with it."

  #230  38e0e7236b11416d429b05a3d3e62e9e5520a1ed
        "feat(rc): advise a stale attach client without touching the endpoint", 2026-09-11 01:38
        attach.rs (daemon), net/attach.rs, rc.rs, docs-site terminal/overview.md, + 5 test files
        b1c665ebcf3273978f68f6e003a0e84b09743fbc
        "test(rc): pin the stale-attach-client advisory at both stages", 480 insertions
        Neither is in main. At HEAD, ATTACH_CLIENT_STALE survives only in the two planning docs,
        which is exactly the shape of doc/impl/unit shipped on a lane that never merged.

Both carry "Co-authored by: todlando" -- this is my own prior work, which makes my "it does not
exist" claim worse rather than better. Noted, not dwelt on.

I take your correction on #230's subject: RELEASE-POLICY-DRIVEN STALE-CLIENT ADVICE, not the generic
attach family I listed. The attach REQs I enumerated last message were generic infrastructure and
were not evidence of #230; the two commits above are.

== 2. THE UNREAD CALLEE WAS THE IMPORTANT ONE, AND IT CONTAINS A LOCK AND A DEADLINE ==

CORRECTION FIRST: I told you "no lock in the read path". THAT WAS WRONG. I grepped the perch,
wansend and visibility modules and reported the result as though it covered the path. It did not
cover `registry::lookup_address`, which I had not read.

THE PATH, now traced end to end:
  roster::enumerate()            roster.rs:62   -- per perch directory
    -> entry_at()                roster.rs:100  -- per perch WITH a readable record
      -> registry::lookup_address(id, owlery)   registry.rs:83
        -> open_registry(owlery)                registry.rs:21
             std::fs::create_dir_all(owlery)
             Connection::open(<owlery>/.registry)        <- A FRESH SQLITE CONNECTION, PER PERCH
             db::tune_connection(&conn)                   <- the waits, below
             conn.execute_batch("CREATE TABLE IF NOT EXISTS agents ...")  <- a LOCK-TAKING statement
             conn.query_row("SELECT address FROM agents WHERE id = ?1")

`tune_connection` (spt-store/src/db.rs:30) holds TWO bounded waits, both per connection:

  (a) conn.busy_timeout(registry_busy_timeout())
      PRODUCTION DEFAULT 5 SECONDS (db.rs:56-75), overridable by SPT_REGISTRY_BUSY_TIMEOUT_MS; the
      doc comment states CI exports e.g. 30000. This is a per-connection retry budget applied to
      EVERY subsequent lock-taking statement -- including the CREATE TABLE above.

  (b) A HAND-ROLLED WAL-SWITCH RETRY LOOP: up to 200 attempts, each sleeping
      5 + (attempt % 10) ms, because the journal-mode switch BYPASSES busy_timeout and fails fast
      with SQLITE_BUSY. The code's own comment bounds it: "Could not switch to WAL after ~1s of
      contention. Proceed anyway."

So the lock is SQLite's, on `<owlery>/.registry`; the deadline is `busy_timeout`, owned by
`registry_busy_timeout()` in spt-store/src/db.rs; and the retry loop is owned by `tune_connection`.
Both are entered ONCE PER PERCH, not once per invocation.

WHY THIS IS A CANDIDATE AND NOT A CONCLUSION. It is consistent with every reported feature:
COMPLETE UNCHANGED OUTPUT and rc=0 (nothing fails -- the waits are retry budgets that then SUCCEED),
a BIMODAL wall (contention present or absent), a LOCAL reproduction with no network involved, and a
PLATEAU (two bounded waits, 5 s and ~1 s, multiplied by perch count). On this box the owlery holds 48
perch directories and 28 readable info.json records, so the multiplier is real.

I am not claiming the observed wait is here. I have not measured a single one of these opens, the
multiplication is arithmetic rather than observation, and a bounded budget is only consumed under
actual contention I have not demonstrated. Per your rules: this narrows candidates; it does not
establish the observed waiting stage.

WHAT I ALSO WITHDRAW, since you named them: "microseconds" for OpenProcess was unmeasured and I
should not have written it -- what the source supports is that it is a single syscall pair rather
than a table scan, and nothing about its latency. "Small files cannot explain ten seconds" was
similarly an argument about byte count, not about I/O latency, and I restated it as such only after
you pushed; it should have been stated that way first.

== 3. THE THREE-COMMAND COMPARISON IS SUPERSEDED, BY MY OWN EARLIER WORK ==

Withdraw it. You were right that three walls are not additive segments, and it is moot regardless:
d5fe86c3 already implements per-stage attribution IN PROCESS, and "registry open/tune/schema/query
work" is one of the stages it names explicitly. My past self evidently suspected this leg. An
in-process stage attribution is strictly better than differencing three process walls -- it
attributes rather than subtracts, and it distinguishes an observation cutoff from producer
completion, which no external timing can do.

So the runtime step, when there is a grant and a free box, is: land or check out d5fe86c3's lane, run
`endpoint list --show-all` with ROSTER_WAIT enabled, and read which stage owns the wall. No new
instrument needs designing. I am not asking for that now -- hertz holds the W2 window through cleanup
disposition and I will not compete with it.

WHAT REMAINS GENUINELY UNTRACED, stated so it is not mistaken for cleared: resource_projection's
internals, VisibilityStore::load, SubnetStore::load, and perch::identity_dir. The UNLISTED worklist
and presence-probe stages that d5fe86c3 names are further evidence there are legs I have not read.

== NEXT ==

Continuing to #49/#267 archaeology now, source and history only, carrying the #42 supersession as
already ruled. Early orientation only, not a finding: the registry family I have to work through
includes REQ-RC-RECONNECT, REQ-RC-RECONNECT-TRUTH, REQ-BRAIN-UPDATE-RESTART-CLEAN-CLOSE,
REQ-BRAIN-RESUME-NO-CONTROL-STEAL, REQ-BRAIN-RESUME-NO-CONN-DEADLOCK,
REQ-HAZARD-BROKER-VIEWER-BRAIN-DECOUPLE, REQ-HAZARD-CONTROLLER-GAP-RESUME, REQ-RC-SINGLE-PUMP-BRAIN
and REQ-DAEMON-REFRESH -- clustered tightly in the registry, which is itself consistent with the
issue's "attemptedly fixed before, more than once".