Share a complete signing key across concurrent first starts

[charan-rathore]

What changed

Starting the server and worker against the same fresh DATA_DIR can fail: both read the missing session-signing-key, then one exclusive write succeeds while the other throws EEXIST. I reproduced three rejected starts out of four calls to createAuth.

Write the generated key to a private temporary file, then publish it with an atomic hard link. If another process publishes first, read its completed key. Remove the temporary file after either outcome. Existing keys and signed links are preserved.

Add regressions for sixteen concurrent first starts, cross-instance signed-link verification, temporary-file cleanup and existing-key reuse. No issue or prior maintainer discussion is claimed. This is distinct from config validation PR #48, whose diff was checked. Open #93 also edits apps/server/src/auth.ts, one line in session(), so a rebase may be needed if it lands first.

Verification

• Exact unpatched main: one regression fails, one passes. Minimal public-API reproduction fails with EEXIST.
• Patched full suite: 278 passed, zero failures.
• Node 24.21.0 focused auth/OAuth/API suite: 16 passed.
• Repository lint, root/mobile/worker type checks and server build pass.

Integration limits

Tests use disposable local directories, synthetic owners and fixture services. No live Google/model accounts or credentials were used. Web/iOS/Android exports, native devices, Chromium lifecycle and Docker checks were not run because this changes server key initialization only.

[jerelvelarde]

Reviewed head 1d7738c5f5fe.

This is a high-value startup reliability fix. The temporary 0600 file plus atomic non-overwriting link ensures concurrent first starts share a complete signing key, and the regression checks cross-instance signed-link validation and preservation of an existing key. No new security or template-fit blocker found in the current diff.

Next step is CI on this head: the current workflow is action_required, so the author-reported passing checks are not yet backed by a GitHub run. I reviewed the diff and current workflow status; I did not rerun tests. I would prioritize this ahead of additional features.

[charan-rathore]

Thanks @jerelvelarde. I rebased onto current main (39a267d), which had only moved by a docs link fix (#129), so the diff is unchanged. The full suite and lint results in the description were from before the rebase, and I did not rerun them after it. The workflow run on this head is waiting for a maintainer to approve it, so CI just needs that approval to run.

[jerelvelarde]

No blocking findings. Writing a private temporary key and publishing it with an atomic hard link makes concurrent initializers adopt one complete signing key without overwriting an existing key. The temporary file stays in the same directory/filesystem, retains mode 0600, and is cleaned up after publication. Unexpected filesystem errors propagate. This is a narrow deployment-reliability fix that preserves the signing boundary and fits the PR template.

Validation: all 16 auth-startup/API/OAuth tests pass locally, including sixteen concurrent initializers, cross-instance verification, existing-key reuse, and cleanup. Root TypeScript and changed-file Biome checks pass. No live credentials were used. Approved the fork CI run and will merge after required checks pass.