factory-sdk: delegate cloud creds to the shared cloud#2108 session module (retire factory-local read+persist)

[khaliqgant]

Follow-up to #323 (which fixed the immediate bug: read canonical ~/.agentworkforce/relay/cloud-auth.json + persist rotated tokens atomically).

Why

#323 is the pragmatic fix, but it still reimplements credential handling inside @pear/factory-sdk — a hardcoded path list, a bespoke onTokens persistence write, and its own atomic-write logic in relayfile-cloud-mount-client.ts. That's a second copy of credential lifecycle logic that can drift from agent-relay / the rest of the cloud#2108 unification.

The architecturally-correct endpoint of relay#1118 / cloud#2108 ("one canonical session, one credential store") is for every consumer to share one resolver + one refresher + one store, so a refresh by any CLI keeps all of them alive and there's a single source of truth for the path and the rotation logic.

What

• Replace the factory-local resolveCloudCredentials / persistCloudCredentials (added in Fix factory cloud creds: read canonical store + persist token rotation #323) with a call into the shared cloud#2108 session/credential module used by agent-relay.
• Single owner of refresh + rotation persistence (avoids the cross-process rotation race noted in Fix factory cloud creds: read canonical store + persist token rotation #323: the live daemon + scheduled reaper + Pear app share a single-use rotating refresh token; concurrent cold refreshes can rotate twice and invalidate each other). Options: a single refresh owner, an advisory file lock around read→refresh→write, or a server-side rotation grace window.
• Keep Fix factory cloud creds: read canonical store + persist token rotation #323's behavior as the fallback until the shared module is importable here.

Acceptance

• factory-sdk no longer hardcodes a creds path or its own persistence; it resolves + refreshes through the shared module.
• Cross-process refresh (daemon + reaper) does not invalidate either party's session.

Refs: #323, relay#1118, cloud#2108.

[khaliqgant]

Status: BLOCKED — holding (decision: option C).

Investigation (subagent team) confirmed the shared module exists and is importable: @agent-relay/cloud@8.7.2 exports readStoredAuth / writeStoredAuth / AUTH_FILE_PATH (canonical ~/.agentworkforce/relay/cloud-auth.json, same path #323 uses). A stacked groundwork branch fix/324-shared-creds-delegation exists (delegates resolution + persistence to the shared module, tests green).

Why we're holding rather than merging: the shared writeStoredAuth (packages/cloud/dist/auth.js:86-91) is a plain mkdir+writeFile — not atomic, no cross-process lock. Delegating persistence to it as-is would (a) regress #323's atomic temp+rename safety and (b) still not solve the cross-process rotation race (factory daemon vs. scheduled reaper). So consuming it now is a net downgrade.

Blocked by → relay#1127 (harden writeStoredAuth: atomic write + advisory lock, then republish). Once that ships and we bump @agent-relay/cloud, #324 becomes a thin consumer swap on top of the existing groundwork branch.

Not blocking anything operational: #323 already fixes the auth bug; #324 is the consolidation.