#4433 stagecraft tracker: tidy up external relations (duplicate entries, id case, second lookup)

Problem

Small gaps in how the built-in tracker handles relations to another tracker's ticket (swamp-club #4376), found by review and left for later:

1. Two entries for one ticket. relate to=linear:ENG-12 while the peer is unreachable stores the reference as written. A later relate to=linear:<uuid> once it is reachable adds a second entry for the same ticket, and repeating the original form returns before any read, so it is never moved to the stable id. A resolved read should also check the peer's display id against stored entries, and could upgrade the stored form.
2. Case-insensitive matching of opaque ids. sameRef in backends/builtin.ts folds case so a display id and stable id match. With a peer whose ids are case-sensitive, relate to=jira:ABC beside a recorded jira:abc records nothing, and unrelate removes the wrong one. Compare exactly and accept the display form as the only alias, or document the assumption.
3. A missed lookup costs a second read. lookup in backends/builtin_peers.ts asks by name, then scans all of that tracker's tickets on a miss. Against a serve that is a second connection (50 a minute per address), and every ticket body crosses for a not-found reference, a display id or an uppercase stable id. A predicate on the record's own id and display would make it one query.

Why not in #4376

None of them gives a wrong status in normal use. Items 1 to 3 have a workaround (unrelate and relate again).

Also, from the last review round of #4376

1. Token file can outlive a stuck read. In swampPeerRun (backends/builtin_peers.ts) the file is removed only when the spawn settles, but remote() abandons a read still pending 2 seconds after its abort. If the child survives SIGTERM, or a descendant holds its pipes, swamp can exit with the private (mode 600) file still in the temp directory. DESIGN.md's "removed however the read ends" is too strong until this is fixed: remove it on abort or when the grace period ends.
2. A relation can become unremovable. Remove a peer named like this instance, or rename an instance to match a stored name:x, and externalOf reads the reference as local, so unrelate throws not_found or removes nothing. Check externalSide(source, type, given) before classifying the reference.
3. unrelate by another name is silent. A relation stored as dev:ABC-1 is not removed by dev:uuid-1, and reports changed: false with the relation still there. Name the external relations of that type to that tracker when nothing matches.
4. The fallback scan has no limit (see 3). On a very large tracker a deleted ticket can report timeout rather than not_found on every fetch_issue. Add --select and --limit, and report truncation distinctly.
5. Typo. REFERENCE.md has a stray .: before the peers example.