Open Project can fail with `no addressing information available` before endpoint publication

[leonfox28]

Problem

Opening a second project from the mobile app through an already-connected Zedra workspace can fail with:

Connection failed: no addressing information available

The target workspace daemon starts successfully, has relay and direct addresses, and stays alive, but the mobile connection does not reach Register or authentication. Retrying after a delay can connect to the same daemon without restarting it.

Expected: after Open Project starts the target workspace daemon and returns its pairing ticket, the app should connect reliably without exposing a transient address-discovery failure.

This appears to be a startup/address-publication race, not a confirmed root cause. The evidence and relevant control flow are below.

Reproduce

1. Start Zedra in project A and connect the mobile app.
2. In the connected mobile workspace, choose Open Project.
3. Select a different local folder (project B) that does not already have a Zedra daemon.
4. Confirm the prompt that runs zedra start --detach --workdir <project-b>.
5. The app navigates to project B, then fails with no addressing information available.
6. On the host, run zedra status --workdir <project-b> and observe that the daemon is ready but has Connected 0.
7. Wait and retry/reopen the same project. The existing daemon can eventually become Connected 1 without a restart.

The failure was observed while trying additional local project folders from the same connected host.

Environment

• Platform: Zedra host on macOS, mobile client platform not captured
• App / CLI version: Zedra CLI v0.4.1; mobile app version not captured
• Device / OS: macOS 26.6.1 (25G76), Apple Silicon; mobile device/OS not captured
• Transport: none during failure; the target endpoint later resolved to a Zedra relay and connected

Evidence

During the failure, the newly spawned daemon reported:

Zedra Daemon

  Version    v0.4.1
  Workdir    /Users/<user>/projects/<project-b>
  Sessions   1
  Connected  0
  Terminals  0

Its startup log showed a healthy endpoint and pairing QR, but no device registration:

--- zedra detached start parent_pid=<project-a-zedra-pid> workdir=/Users/<user>/projects/<project-b> ---
Zedra Daemon Started

  Relays        sg1, vn1, us1, eu1
  Direct Addrs  3
  Workdir       /Users/<user>/projects/<project-b>

Metrics captured while the error was visible:

{
  "daemon_starts": 1,
  "successful_connections": 0,
  "new_pairings": 0,
  "qr_codes_created": 3
}

This indicates that the mobile request failed before host-side registration/authentication. Later, the endpoint's pkarr URL returned HTTP 200 and its DNS TXT record contained a Zedra relay. Without restarting the daemon (same PID and continuous uptime), the workspace subsequently changed to Connected 1.

The v0.4.1 control flow also supports a possible readiness race:

• open_workspace_inner starts the detached daemon, obtains a pairing ticket, and returns it.
• wait_for_detached_pairing_qr waits for the daemon's local /api/qr endpoint, but does not verify that remote addressing information is resolvable.
• The host attaches PkarrPublisher::n0_dns() when binding the endpoint, while Iroh documents the publisher update as nonblocking/background work. The app then immediately starts connecting with the returned id-only ticket.

Possible fixes:

• Treat an empty address lookup for a newly opened workspace as transient and retry with bounded backoff.
• Wait until the target endpoint has published resolvable relay/direct addressing before returning HostWorkspaceOpenResult.
• Return usable relay addressing through the authenticated remote-open response so this path does not depend on a just-published pkarr record.

A regression test could start a fresh daemon through HostWorkspaceOpen and immediately connect using the returned ticket, with address publication intentionally delayed.