fix(app-shell,plugin-detail): the chatter chain gets a loading signal source (#3209) (#3270)

The discussion panel spent every feed fetch asserting "No comments yet" — a
factual claim about the record — then contradicted itself when the rows landed.
#3205 gave RecordActivityTimeline the render branch that prefers a loading row
over the empty copy, and RecordChatterPanel already forwarded `loading` to it in
both positions, but on the chatter chain nothing PRODUCED the signal, so the
branch could never fire. `record:activity` computes its own flag and was fixed
by #3205 on sight; chatter was not.

Closes all four wiring points, because any one left open still ships the empty
copy to some user:

  - RecordDetailView — the host that owns the fetch — derives `feedLoading`
    from its two reads (sys_comment + sys_activity);
  - <DiscussionContextProvider loading={feedLoading}> publishes it (the field
    was already declared on DiscussionContextValue and already read by
    `record:activity`);
  - the auto-appended <RecordChatterPanel loading={feedLoading}> — what
    authored pages that place no discussion slot get — takes it directly;
  - the `record:chatter` / `record:discussion` renderer forwards
    `loading={discussion?.loading}`, putting hand-placed blocks on the same
    chain as the synthesized one.

The two reads are parallel promises, so the flag closes over BOTH: it clears on
Promise.allSettled, and a REJECTED read counts as an answer (sys_activity 404s
without the audit plugin, sys_comment 403s under `enable.feeds: false`) — a
permanent spinner would be worse than the bug being fixed. The flag is keyed by
`object:recordId` rather than a plain boolean so the first render of a record
already reads as loading (no one-frame flash of the empty state) and navigating
between records cannot show the previous record's settled answer.

No consumer-side tolerance was added: the timeline still does not guess that
"no items yet and just mounted" means loading. Same shape as #3165 / #3205 —
divergence converges at the producer.

Tests pin the rendered outcome (loading row vs. empty copy), not prop passing,
on both delivery paths — the synthesized page's DiscussionContext hop and the
authored page's auto-append — plus the one-settled-of-two and rejected-read
cases. Each of the four wires was mutation-verified red.


Claude-Session: https://claude.ai/code/session_01NVPjPzmmAJ2Ngtvgg5MSRa

Co-authored-by: Claude <noreply@anthropic.com>

Author: xuyushun441-sys

.changeset/record-chatter-loading-signal.md

@@ -0,0 +1,49 @@
+---
+"@object-ui/app-shell": patch
+"@object-ui/plugin-detail": patch
+---
+
+The record discussion panel now says "loading" while it is loading, instead of
+"No comments yet" (objectui#3209).
+
+FROM: opening any record page showed the discussion/chatter panel asserting
+`No comments yet` for the whole first leg of the page, then contradicting
+itself when the comments appeared. TO: the panel shows the loading row until
+the feed has actually answered, and only then commits to "this record has no
+comments".
+
+objectui#3205 gave `RecordActivityTimeline` the render branch that prefers a
+loading row over the empty copy, and `RecordChatterPanel` already forwarded
+`loading` to it in both positions — but on the chatter chain **nothing
+produced the signal**, so that branch could never fire. `record:activity`
+computes its own flag and was visibly fixed by #3205; chatter was not. The
+four wiring points are one chain and are all closed here, because any one of
+them left open still ships the empty copy to some user:
+
+- `RecordDetailView` — the host that OWNS the feed fetch — now derives a
+  `feedLoading` flag from its two reads (`sys_comment` + `sys_activity`);
+- `<DiscussionContextProvider loading={feedLoading}>` publishes it (the field
+  was already declared on `DiscussionContextValue`, and already read by
+  `record:activity`);
+- the auto-appended `<RecordChatterPanel loading={feedLoading}>` — the panel
+  authored pages get when they place no discussion slot — receives it
+  directly;
+- the `record:chatter` / `record:discussion` renderer forwards
+  `loading={discussion?.loading}`, so a hand-placed block is on the same
+  chain as the synthesized one.
+
+The two reads run in parallel, so the flag closes over **both**: it clears on
+`Promise.allSettled`, and a REJECTED read counts as an answer. A deployment
+without the audit plugin 404s `sys_activity` and an object with
+`enable.feeds: false` 403s `sys_comment`; neither may pin the panel in a
+permanent spinner, which would be a worse bug than the one being fixed. The
+flag is keyed by `object:recordId` rather than being a plain boolean, so the
+first render of a record already reads as loading (no one-frame flash of the
+empty state) and navigating between records cannot show the previous record's
+settled answer.
+
+No tolerance was added at the consumer. The timeline still does not guess that
+"no items yet and just mounted" means loading — that guess is wrong the moment
+a record genuinely has no comments, and the signal belongs to whoever owns the
+fetch. Same shape as objectui#3165 / #3205: divergence converges at the
+producer.