Context

When files are removed between review rounds in crit local, their comments are preserved and displayed with a "Removed" badge and italic placeholder (PR #279). When these reviews are shared to crit-web, the orphaned files are included in the payload but crit-web has no rendering support — comments on removed files are effectively lost in shared reviews.

Current behavior

• buildShareFromSession (share.go:189) sends orphaned files as shareFile{Path, Content: ""} — no orphaned or status field
• crit-web receives an empty-content file with comments but doesn't know it was removed
• document-renderer.js has no orphaned file concept

What needs to change

1. Share payload (crit/share.go)

Extend shareFile to carry status metadata:

type shareFile struct {
    Path     string `json:"path"`
    Content  string `json:"content"`
    Status   string `json:"status,omitempty"`
    Orphaned bool   `json:"orphaned,omitempty"`
}

buildShareFromSession populates from f.Status and f.Orphaned.

2. crit-web API + storage

The review creation endpoint needs to persist the status/orphaned flag per file. Design question: is this a new column on the files table, or metadata in the JSON blob?

3. crit-web/document-renderer.js

Port the rendering logic from crit's app.js:

• "Removed" badge on file header (app.js:1756 — file.orphaned check)
• No "add comment" button (app.js:1820 — if (!file.orphaned))
• All comments rendered as file-level (app.js:1852 — isOrphaned ? file.comments : ...filter(...))
• Italic placeholder instead of content body (app.js:1889-1893)
• CSS: .orphaned-placeholder, .file-header-badge.removed, --crit-badge-removed-* variables

4. CSS theme variables

Add to all 4 theme blocks in app.css:

• --crit-badge-removed-bg
• --crit-badge-removed-fg
• --crit-badge-removed-border

Open questions

• Should crit-web allow adding new comments to orphaned files in shared reviews? (crit local doesn't — shared reviews are read-only anyway)
• Should the share payload be backwards-compatible? (Old crit-web instances would ignore the new fields, which is safe — they'd just render empty files as before)