[Bug]: iOS Live Activities toggle always fails with "Invalid managed endpoint origin" (link-proof called over LAN/tunnel, host accepts loopback only) #27412

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/mobile, apps/server (T3 Connect link proof)

Steps to reproduce

1. On a macOS desktop host, turn on Network access, T3 Connect and Publish agent activity (Settings → Sharing & access). T3 Connect shows as on with 1 tunnel in use.
2. Pair the iOS app with that host. The connection has relay:write.
3. On iOS, open Settings → Notifications and turn on Live Activity Updates.

Expected behavior

Live Activities turn on for this device. The host is already linked to T3 Connect, so the phone shouldn't have to obtain a new environment link proof.

Actual behavior

The toggle stays off and an alert appears every time:

Live Activities unavailable
Could not obtain environment link proof: Invalid managed endpoint origin.

The phone reaches the host over the LAN or the T3 Connect tunnel, so POST /api/connect/link-proof always arrives on a non-loopback host. In makeCloudLinkProof, isAllowedEndpointOrigin rejects a non-loopback request host unless allowNonLoopbackRequestHost is set, and that is only true when the principal is desktop-bootstrap. A paired phone can never satisfy this check.

This looks like the gap left by #14252. That fix skips environment linking when the connection lacks relay:write. When the connection has relay:write, the toggle still calls link-proof and fails on the origin check. #5210 / #11567 hit the same loopback-only rule from a WSL desktop.

Impact

Major degradation: Live Activities can't be turned on from the phone at all. Device notifications still work.

Version or commit

Desktop/server: 0.1.6-nightly.20261030.3904 (macOS). iOS app: current build (exact build number not captured). Reproduced repeatedly over several days.

Logs or stack traces

Host server trace, one entry per toggle attempt:

environment.cloud.makeLinkProof  exit: Failure
CloudLinkOriginInvalidError: Invalid managed endpoint origin.
    at environment.cloud.makeLinkProof
    at environment.cloud.linkProof
    at server.runServerCommand

Root cause (as far as we can tell)

The Live Activities toggle on the phone tries to link the host to T3 Connect again, and the host only accepts that request from itself.

1. setLiveActivityUpdatesEnabled saves this device's preference with the relay. It then calls linkEnvironmentToCloudWithPreference for every saved connection that has relay:write (liveActivityPreferences.ts:27).
2. That function does a full relink, which includes POST /api/connect/link-proof on the host (linkEnvironment.ts:190).
3. The host refuses link proofs whose request host isn't loopback (linkChecks.ts:91). The only exception is the desktop app's own desktop-bootstrap session (CloudLink.ts:635-640).
4. A phone always reaches the host over the LAN or the T3 Connect tunnel, so step 3 always fails. The onError rollback then reverts the device preference (liveActivityPreferences.ts:77).

Proposed fix

Change the phone only. The toggle saves this device's Live Activities preference with the relay and stops relinking hosts. The server's loopback check stays as it is, because it is a security boundary.

The host already links itself with liveActivitiesEnabled: true (CloudLink.ts:878-885), so the phone relink looks redundant. Locally the patch is small (3 files in apps/mobile). Mobile typecheck, lint and the agent-awareness and settings unit tests pass. I haven't tested it end to end; see the comment below for why.

Open question

The relay isn't in this repo. RelayEnvironmentLinkRequest carries an optional deviceId and a per-link liveActivitiesEnabled (relay.ts:322-331). Does the relay need a (device, host) link created from the phone before it delivers Live Activities to that device? Or is the host's own link plus the device registration enough?

If the host's own link is enough, the fix above should be correct. If the relay does need a link from the phone, the fix belongs somewhere else, probably in the relay or in how the host links.