Bound the Enclave connect, retry at boot, and classify the failure

A blocking connect(2) on apiary's single cooperative scheduler took the kernel's full ~135s SYN-retransmit budget, and for that whole time NO MCP request could be answered -- including ones that touch no network at all. Measured against tools/list over a 240s outage: 53/120 answered, with one contiguous ~134s dead window. Healthy control in the same session: 20/20.

WHY THIS IS ONE COMMIT AND NOT TWO.

Bounding the connect and adding boot-time retry look independent. They are not, and the trap is asymmetric. Before this change a failed boot connect was terminal, so dispatch RECOVERED once the process had given up -- the wedge ended precisely when apiary became permanently useless. Adding retry alone would convert a 134s wedge followed by a dead-but-responsive process into one wedged for the entire outage. Bound first, then retry, is safe in that order only. Two changes are independently shippable only if EVERY ordering leaves the system no worse; this pair fails that test, so they ship together.

WHAT CHANGED.

Apiary now opens the transport itself and hands the ready socket to sigil-irc, rather than calling irc-connect, which performs an unbounded connect with no way to pass a deadline.

• TCP connect is bounded and CLASSIFIED via %tcp-connect-ip-timeout-status, which distinguishes refused / timed out / host unreachable / network unreachable. The whole call shares one budget across every resolved address, so N addresses cannot multiply into N x the bound.
• The TLS handshake is bounded SEPARATELY via tls-upgrade/status. Once a peer accepts the TCP connection the connect phase is over, so the connect bound cannot reach a peer that then goes silent -- that read had no bound at all. tls-connect/status was rejected because it collapses every connect-phase failure into one "tcp-connect-failed" status, which cannot tell refused from blackholed and so defeats the point.
• Certificate verification is unchanged: tls-upgrade and tls-connect configure VERIFY_REQUIRED against the system CA chain identically. Read in sigil-tls's native source rather than assumed, because a silent downgrade here would trade an outage for an MITM window.
• enclave-bridge-run! retries the boot connect with the same backoff the established-connection path uses. Previously a process that booted during an outage never connected again for its whole life while still advertising every tool.
• Tool results now distinguish "not connected yet, retrying (attempt N; last failure X; next attempt in Ms)" from "will NOT connect (terminal)". Both used to be "Error: enclave bridge not connected", so a process that would never recover read exactly like one two seconds from succeeding.

The connect bound (5s) sits deliberately below the 30s PONG timeout. The comment records what that does and does NOT buy: overlapping reconnects are actually prevented by the reconnecting? flag, and the ordering is defence in depth on top of it.

MEASURED, baseline vs this build on the same harness:

  blackhole dispatch, 240s   53/120 answered  ->  102/120
  longest single stall       ~134s            ->  ~4s
  boot during outage         never recovers   ->  connected 4.5s after the
                                                  endpoint returns
  error discrimination       1/5              ->  4/5, log and tool level
  clean network switch       89.1s / attempt 1 at +9.3s / zero stall
                          -> 84.4s / attempt 1 at +9.3s / zero stall

The clean-switch difference is not an improvement and is not claimed as one -- both sit inside the 60s-idle plus up-to-30s-PONG window.

This also removes a pre-existing leak: the old enclave-connect spawned the event loop BEFORE the registration wait and raised on timeout, leaking a live socket and a goroutine on every failed boot.

Relocks sigil-tls 0.16.3 -> 0.16.5 for tls-upgrade/status. sigil-irc moves 0.16.1 -> 0.16.2 within its caret range; its src trees are byte-identical, so the bump is inert for the registration internals this depends on.