fix(audit): mine doc_replicated copies and audit project document uploads

WHY THIS MATTERS
The history feature under-recorded reality in two ways. Replicated documents
were attributed to the wrong file and lost their id, and project document
uploads were never recorded at all - so the audit trail silently disagreed with
what the user actually did.

WHAT IS EVENT MINING
recordChatTurn derives one audit row per artifact a chat turn produced by
walking the persisted assistant-event stream (doc_created, doc_edited,
doc_replicated, workflow_applied). Each event type stores its payload
differently, so the miner has to read each shape correctly.

HOW IT WORKS
- doc_replicated (F6): per chat/streaming.ts, this event's top-level `filename`
  is the SOURCE document and there is no top-level document_id - the produced
  copies live in a `copies: [{ new_filename, document_id, version_id }]` array,
  and one event can produce several. The miner previously read the top-level
  fields, so it logged one row titled with the source filename and a null id.
  It now iterates `copies`, emitting one document.generated row per copy with
  that copy's new_filename and document_id.
- Project uploads (F6): POST /projects/:id/documents calls the project-scoped
  handleDocumentUpload in projects.ts, a duplicate of the instrumented one in
  documents.ts, and it had no recordAudit call - so project uploads never
  appeared in history. It now records a document.uploaded event
  (surface: "project", the project id, the new document id) on success,
  fire-and-forget like the sibling handler.

Tests exercise the miner directly: a mixed turn (created/edited/workflow) maps
to the right actions, a doc_replicated with two copies yields exactly two
document.generated rows carrying the copies' filenames/ids (and never the source
filename), and an empty-copies event yields only the chat.message row.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>