Logged-in-aware exposed state of cloud.datum.net that can only be read by datum.net #893

High-Level Summary

Every goal in #890 (nav/CTA personalization, signup-prompt suppression, roadmap voting attribution, form prefill, etc.) needs one prerequisite: a way for datum.net to know whether the current browser is signed in to Datum Cloud (cloud.datum.net) — without exposing that signal to any other origin.

Today that signal doesn't exist. This issue is scoped to just building it — not to any of the personalized UI that consumes it (that stays tracked under #890 and its other sub-issues).

Current state (verified)

• cloud-portal's session cookie (_session, AUTH_COOKIE_KEYS.SESSION) is set with domain: new URL(env.public.appUrl).hostname (app/utils/auth/auth.service.ts) — i.e. scoped to cloud.datum.net's own hostname, httpOnly, sameSite: lax. It is not shared across .datum.net, so the browser never sends it on a datum.net request. This is the correct, secure default — not a bug to fix in cloud-portal.
• datum.net's repo already has a stub at src/pages/api/user.ts that tries to read a _session cookie directly and calls the IAM API with it. Because of the point above, this cookie is never actually present on a datum.net request in production — the endpoint is effectively dead code today. It isn't wired into Nav.astro or anywhere else in the UI.

The ask

Design and implement a narrow, purpose-built way for datum.net to learn "is this visitor currently signed in to Datum Cloud" (and probably a minimal display payload — name/org — TBD by design), that:

• Only datum.net (https://www.datum.net / https://datum.net) can read — not an arbitrary third-party origin
• Leaks nothing beyond what's needed for personalization (no tokens, no scopes, no permissions)
• Fails closed: any error, timeout, or ambiguous state renders datum.net as if the visitor is signed out

Candidate approaches to evaluate at design time (not prescribing one):

• A dedicated endpoint on cloud.datum.net (or auth.datum.net) that responds to a credentials: 'include' cross-origin request from datum.net, with CORS locked to that exact origin, returning a minimal { signedIn: boolean, displayName?, orgName? } shape
• A short-lived, purpose-scoped signed token/postMessage handshake instead of a raw CORS+cookie read, if the team wants to avoid widening cookie/CORS trust between the two apps

This spans at least cloud-portal (and/or auth-ui) plus datum.net — flagging as cross-repo/backend-required.

Non-Goals

• Any personalized UI itself (nav CTA swap, signup suppression, roadmap voting, form prefill, etc.) — those are separate, downstream sub-issues of Create a more personalized website experience for users #890
• Changing where/how cloud-portal's own session cookie is scoped — it should stay app-local; this issue is about a separate, narrowly-scoped signal for datum.net to consume, not widening the existing session cookie's trust boundary

Relationship to #890

Sub-issue of #890 — blocks the "Navigation and primary CTA" and "Suppress signup prompts globally" goals listed there at minimum; several of the other goals (roadmap voting attribution, form prefill) will also need this signal or an extension of it.