add community creation flow

docs/concord-simplification-plan.md

@@ -282,6 +282,33 @@ the base64 record). `cargo clippy -p concord --all-targets` and
    arity, `set_pin_list`'s missing `.await`, the GPUI `init` signature and
    registry names, and the "Not wired up yet" registry bullet.
 
+### Phase 5 — sidebar calls `create` — DONE
+
+The last blocker was that nothing invoked `CommunityRegistry::create`; the
+running app logged `community load: 0 state document(s) found` and `subscribe`
+never ran. The sidebar now:
+
+1. Renders `CommunityRegistry::communities()` instead of the hardcoded
+   `dummy_communities()`. `SidebarRow::Community` carries an `Entity<Community>`,
+   labelled with `Community::name()` (control-fold metadata, falling back to the
+   community id until the first fold).
+2. Adds a "New community" row to the Community section that opens a name prompt
+   and calls `CommunityRegistry::create` with default metadata. Relays stay empty,
+   so the subscription resolves through `ReqTarget::auto` against the pool's
+   relays rather than a manual target that `add_relay` might not have connected.
+3. Observes the registry, so a `track` or fold re-render reaches the list, and
+   subscribes to `CommunityEvent::Error`, which is now logged
+   (`log::error!("community: {error}")`) instead of vanishing. A `cx.notify()` in
+   the registry's per-community observer propagates the fold that fills in the
+   name.
+
+Validation: `cargo check -p workspace -p community --all-targets`,
+`cargo test -p community` (1 passed), `cargo clippy -p workspace -p community
+--all-targets`, and `cargo fmt -p workspace -p community --check` are clean.
+
+Still local-only: the genesis is persisted but not published to relays, so a
+second account cannot discover the community yet.
+
 ---
 
 ## 3. Retained-by-decision surface (reference only)

docs/concord-usage.md

@@ -542,9 +542,10 @@ client.subscribe(filter).with_id(sub_id).await?;
   `crates/community`.** `concord` has no subscriptions, no `init`, and no
   `Entity<Community>`; `community::CommunityRegistry` owns one `Entity<Community>`
   per state document, subscribes when a community's plane set changes, and
-  re-folds on an inbound wrap. Nothing observes `CommunityEvent` yet, and
-  `CommunityRegistry::create` persists the genesis locally without publishing it
-  to the metadata's relays.
+  re-folds on an inbound wrap. The sidebar observes the registry, logs
+  `CommunityEvent::Error` through `log::error!`, and its "New community" row opens
+  a name prompt that calls `CommunityRegistry::create`. `create` still persists
+  the genesis locally without publishing it to the metadata's relays.
 - **Account-key writers take any signer, not `&Keys`.** `genesis`,
   `ControlWriter`, the guestbook and chat `seal_rumor`s, the `list` builders, and
   the `cord05` invite writers (`build_direct_invite` / `unwrap_direct_invite`,