fix(lock): make a leaked registry lock visible, and budget the wait in seconds

[fujibee]

Declared reviewers: 1

References #778 and #779. No closing keyword — integration/remote is not the
default branch, so one would not fire, and #779's Node-side half is untouched.

Measured once, at head f924c833caaa297398d9f9c0b9f2f01143215b9f.

#778 — a leaked lock could not say whose it was, or that it was stuck

The lock directory was created empty, so a lock that leaked said something held
it and nothing about what. agmsg_lock_acquire writes pid, command, host and a
token beside it — <lock>.holder — as it takes the lock.

And rmdir "$l" 2>/dev/null || true at both release sites treated "already
gone" (a released lock) and "will not go" (the permanent leak this file promises
not to leave) as the same event. Release reports the second and stays quiet
about the first, with a remedy that works on the case that produced it.

#779 — the wait was counted in attempts and announced in seconds

1000 attempts with "= ~10s" beside it. Measured before changing anything: 100
attempts take 3 seconds, three times the stated figure, on the platform this
was written on. AGMSG_LOCK_SECONDS (default 10) is the budget;
AGMSG_LOCK_TRIES stays as a ceiling — derived, not assumed: set in four
places, all tests, none in production.

Every hazard in this branch was one the branch created

Five review rounds, and each finding was a defect in the previous round's fix
rather than in the original code. Recorded because the pattern is the point:

• the remedy printed rmdir — the command that had just failed. Running the
  printed line is what caught it.
• release could delete a SUCCESSOR's lock — the sequence the new remedy
  invites: operator removes it, another process takes the path, the original
  release deletes theirs. Ownership is checked against the token now.
• the token was per process, and this library holds several locks at once —
  its own opening comment says so. Both locks leaked. Tokens are per lock path.
• a failed removal restored only the token, losing pid/command/host — the
  diagnosis disappearing exactly when it is needed.
• the holder lived inside the lock, so rmdir needed rm to succeed. The
  core join path runs under an allow-listed PATH with no rm, and leaked a lock
  on every call. The holder is a sibling now, tidied when the lock goes.

Controls

swallow the release failure again        2 red
drop the holder write                    1 red
remove the time bound                    2 red (red, not hanging — an earlier
                                         version of that test hung instead)
disable the ownership check              3 red
restore only the token line              1 red
constant nonce, either branch            1 red
unquote the printed remedy               1 red

Checks

test_registry_lock    14        test_type_registry     20
test_actas_lock       22        test_local_team_ids     5
test_plugin_registry   9        test_team              76
                                          no failures
drift at push time    structurally empty (merge-base == the base)

Every test that was red at any point on this branch passes here, each compared
against the base rather than assumed: core join does not require python3,
disconnect: no replacement can land …, both rename-team cases, and
releasing the engine's own lock leaves other held locks alone.

bats (ubuntu-latest 4/4) fails at not ok 265 watch: relaunch with the SAME instance id replaces the previous watcher, on _wait_pidfile "$pf" "$w2" —
the test and the assertion #595 already names. Tracked there. This branch cannot reach it: watch.sh reaches
registry-lock.sh only through reset.sh, guarded by if [ -n "$DESPAWN_TARGET" ],
and the failing test never sets it. That is one path closed, not a proof of
innocence.

Not in this change

Cleaning up a lock left by a dead process — a real hazard (deciding a live lock
is dead) and not what #778 asks for. The Node-side iteration budgets #779 also
mentions are in remote-sync.mjs, which other branches are editing.