"Referenced by" panel: related-document links from a shared reference index

[criptogus]

Summary

Add a discreet "Referenced by" / related-documents panel per file: which other documents reference this one, and which ones this one references. Not a visual graph — a small sidebar/list that shows document relationships the way a "Linked mentions" list does.

Motivation

• Work products are connected: a proposal references the PRD, a contract references the proposal, a board pack aggregates reports. Today nothing in the app reflects that; every link lives only in the agent's head.
• The plumbing already exists: packages/project-store keeps a ProjectIndex (absolute path → projectId) and chatIdByPath (stable sha256 per file path) — adding a reference index is metadata, not a new paradigm.
• Keeps navigation intuitive: it's a list, not a canvas/graph — the same mental model as "see also" in a wiki, which office users already know.

Proposed UX

• In the editor (docs/sheets/slides) and on Home file rows: a "Linked files" affordance (e.g. a small chain icon in the tab bar / sidebar) opening a panel listing:
  • References: files whose content mentions this file's name (or an explicit link/mention).
  • Referenced by: files this one mentions.
• Rows are clickable → open in new tab. Count badge on the affordance ("3").
• Detected via two signals:
  1. Explicit: a lightweight link syntax in documents (e.g. [[FileName]] or a styled hyperlink) — the app's link handling already exists in docs (linkifyPaths in docs/pdf).
  2. Implicit: filename mention in extracted text (same extraction path as full-text search — share the indexer; see related issue).
• No graph view, no canvas — a plain two-section list. (If community later wants a graph, it can be built on the same index in a separate feature.)

Implementation notes

• Index: extend packages/project-store with a reference table (src/types.ts + store.ts): refsByPath: Record<path, { out: string[], in: string[] }> populated from (a) links found during extraction (share crawl with the full-text search indexer — design both together so there's ONE crawl), (b) filename mentions.
• Storage: persisted alongside project data in the project-store location; rebuilt incrementally on file change/recents change.
• UI: panel in the shell renderer next to the editor area (or in Home detail view); new channels in home-api.ts (refs:get, refs:changed event) + preload.
• Link extraction: reuse linkifyPaths (currently duplicated in docs + pdf — see issue Extract duplicated linkifyPaths (docs + pdf) into a shared module with unit tests #15 to extract it to a shared module first) so explicit links and the references index agree on what a "link" is.

Acceptance criteria

• Opening a file with references shows the panel with correct in/out lists (manually created test fixture with 2 linked docs).
• Counts update when documents are created/renamed/deleted (path changes propagate — note chatIdByPath is stable across renames; refs should survive a rename of the referenced file).
• Clicking a referenced file opens it in a new tab.
• Index persists across restarts and is rebuilt incrementally.
• Zero impact on editor performance for files without references.

Out of scope

• Graph/canvas visualization (separate feature, same index).
• Auto-linking on write (typing [[ completion) — v1 is read-only relationship discovery.
• Cross-machine reference sync.