Replies are atoms; threading is a self-FK pointer, not a separate type

The substrate doctrine says everything is an atom. We already had references_atom_id in the schema as a self-FK for threading; what was missing was the UI surface and the visibility-gated listing query.

Why atoms-as-replies (not a separate atom_comments table):

• A reply is a piece of substrate content, with all the same affordances — visibility, intent tags, bookmarks, reactions, its own replies. Modelling it as anything other than an atom would duplicate everything atoms already have.
• The reply's visibility is independent of the source's: you can reply privately to a public post, or post a public reply to one of your circle's. The reader is filtered by the same buildVisibilityClause that gates the rest of the substrate.

How this differs from comments-on-decisions:

• Decisions are governance artifacts, not content. Their commenting uses the shared comments table because they need flat threaded pushback, not rich substrate atoms.
• Atoms-as-content needs the full atom shape (intent tags, lens filters, etc.) on every reply. Comments would lose that.

Threading depth at v0.5: replies render as a flat chronological list under the source atom. Visual nesting is a v0.6 polish — each reply is its own atom permalink, so the deeper structure is queryable but not visually nested.

Anti-leak gate: the compose page server-side validates the ?reply=<id> URL param via getAtomForViewer — if the viewer can't see the target, the reply context is silently dropped. Same gate on composePostAction. This keeps an attacker from probing atom existence by trying random reply targets.