Retry zrok token setup after stale-environment cleanup

[qayshp]

Summary

• detect zrok's exact you already have an enabled environment failure when setting an auth token
• disable that stale local environment and retry zrok enable <token> exactly once
• stop immediately if cleanup fails and preserve the existing disable error
• keep existing invalid-token and generic-error behavior for both the initial attempt and retry
• add focused ProcessSpawner.executeCommand tests for the bounded recovery paths

Root cause

ZrokManager.setToken() recognized the stale-environment error but returned its output as though token setup had succeeded. The stale environment remained enabled, so later share creation could continue failing. The issue's manual workaround—running zrok disable before enabling through BlueBubbles—showed the required recovery sequence.

Behavior and safety

Only output containing the existing exact zrok condition triggers recovery. The sequence is bounded to:

1. zrok enable <token>
2. zrok disable if the stale-environment condition is returned
3. one final zrok enable <token> attempt

There is no recursion or unbounded retry. If disable fails, recovery stops before a second enable and preserves Failed to disable Zrok tunnel!. Invalid tokens remain Invalid Zrok token!; unrelated failures retain the existing generic error.

Validation

Validated on current head 0cd1cb84:

• npm run test:zrok --workspace packages/server — 7/7 tests passed
• the committed seventh test verifies that a failed disable stops at enable → disable, performs no second enable, and preserves the exact existing disable error
• targeted ESLint, Prettier, and git diff --check passed

Limitation

No recovery was run against a real disposable zrok token/environment. The command sequence and errors are validated at the mocked ProcessSpawner boundary; this PR does not claim an end-to-end live zrok recovery pass.

The broader server type-check still reaches the pre-existing unrelated ScheduledService.ts:39 NodeJS.Timer/clearInterval error.

Fixes #678

[qayshp]

Self-review found one focused follow-up for the newly introduced recovery path.

[qayshp]

Validation update

Validated the mocked command paths on SIP-enabled arm64 macOS 26.5.2 with Node 20.11.1 and npm 10.2.4.

• npm run test:zrok --workspace=packages/server — 6/6 committed tests passed.
• A separate no-file-change test harness exercised a failing intervening disable: recovery stopped after enable → disable, made no second enable attempt, and preserved the existing Failed to disable Zrok tunnel! error.

That failure case was not added to the committed test suite, so the review follow-up remains open. Live recovery is deferred because this machine has no enabled zrok environment. Reproducing it requires a disposable zrok token/environment and will change both local and external zrok state; SIP is not the blocker.

No messages were sent or received during validation. No screenshot is needed because the command sequence and resulting state are the relevant evidence.

[qayshp]

Superseding the earlier validation note: current head 0cd1cb84 contains the committed disable-failure case, and the focused suite re-passed 7/7. The test confirms recovery stops at enable → disable, makes no second enable attempt, and preserves the exact existing disable error.

No test used a real disposable zrok token/environment, so this remains mocked command-boundary validation and is not an end-to-end live recovery claim.