Pod creation: replace the one-line prompt with a considered flow

[lilyshen0722]

Extends #732 (fresh-user audit), scoped to the creation moment specifically.

Today "+ New Pod" offers almost no choice and no explanation, so a user cannot express intent at the point they have it — and the one choice it does offer is inert (see the ADR-016 issue).

Blocked on ADR-016 — building a richer flow before the model is decided just makes a nicer UI for the wrong concepts. Sequence: decide the model, then design the flow, then build.

Worth noting the flow is also where the product explains itself to a first-time user. Right now it explains nothing.

[lilyshen0722]

Slice 1 shipped — label accuracy only, no behavior change: PR #778. "Private" no longer means three different things; the creation card now names the one field it actually sets (join policy).

Proposal for the modal (design only — build blocked on #768/ADR-016, as scoped):

The current card tangles three orthogonal facts, and the modal should express them as what they are:

1. Kind — dm vs room (idea-register P1). DMs are never created from this modal, so the modal creates rooms, full stop. No "type" choice shown to users.
2. Who can join — joinPolicy (the one thing the card sets today).
3. Who can find/read it — communityListed / publicRead (owner-settable only after communityListed has no writer — pods cannot be listed to Community via any API #772).

Modal shape:

• Step 1 (always): name + goal. Goal is the pod's brief — it feeds agent context, so the modal should say that ("Agents in this pod read this"). This is also where the product explains itself to a first-time user; one sentence of "what's a pod" microcopy on first run only (sessionStorage, same pattern as the starter panel).
• Step 2: one "Access" choice, presented as presets, not raw booleans:
  • Invite-only (default) — you add people; not listed anywhere.
  • Open via Community — listed in Community, anyone can join. Requires communityListed has no writer — pods cannot be listed to Community via any API #772's owner endpoint; disabled with an explanatory note until it lands.
  • (Later, not v1) Public showcase — readable without joining. publicRead is admin-curated today, so it stays out of the modal until that changes.
• Each preset renders a summary line of the concrete facts ("Listed in Community · anyone can join · members-only reading") so the model stays legible and the presets can only produce coherent combinations — which also designs away the {publicRead:false, communityListed:true} joinable-but-invisible contradiction at the UI layer, whatever rule communityListed has no writer — pods cannot be listed to Community via any API #772 lands on.

Why decide #768 first: if it lands as P1 (kind + three explicit settings), this modal is a thin skin over exactly those settings — that's the argument for the sequence, and why I didn't build it now. The "Team" filter excluding My Workspace (type:'chat') is the same model question and stays open with it.

[lilyshen0722]

Proposal amendment (after #772 spec alignment in the pod — the writer enforces listed ⇒ publicRead, and the join gate is the full discovery predicate):

1. "Open via Community" disabled state: listing is admin-curated for now (owner-side "request listing" is communityListed has no writer — pods cannot be listed to Community via any API #772's documented phase 2), so the preset stays disabled for non-admin owners even after communityListed has no writer — pods cannot be listed to Community via any API #772 lands. Disabled hint should say so plainly — "Community listing is admin-curated for now" — rather than leaving owners waiting on a button. For admin creators the preset can enable as soon as the writer ships. When phase 2 arrives, the disabled state upgrades to a "Request listing" action (same shape as idea-register H5: a request with a reason, not a silent wall).
2. Summary line for the live preset: can safely promise "anyone can find and join this pod" — the server invariant means those can't diverge again. It must also disclose the coupling the invariant creates: listing now implies publicRead, so choosing this preset makes the pod readable without joining. Summary line becomes: "Listed in Community · anyone can find and join · readable without joining." Omitting the readability fact would be the same word-vs-behavior gap this issue exists to close.

No change to the label-accuracy spec — "Anyone can join if this pod is listed in Community." survives #772 as written (confirmed by @pod-architect: every state the system can now produce makes it true and complete).