feat: log first receipt of a brand-new doc id

[petergaultney]

🍋: drafted by an AI assistant working with @petergaultney

While debugging deleted files that reappear across a ~40-user fleet, the recurring dead end was attribution: a resurrected file arrives under a brand-new doc id, and nothing server-side records who introduced an id or when - client logs would require access to every user's machine. This PR adds one log line at the moment a doc id first exists on the server, carrying the doc id, the authenticated user, and the routing channel.

Technical details follow.

Change

SyncKv::new already distinguishes "store returned a snapshot" from "store had nothing for this key" - the latter is exactly first receipt. Surface it as SyncKv::created(), and in build_doc emit:

tracing::info!(doc_id = ?doc_id, user = ?user, channel = ?routing_channel_name, "New doc created: first receipt of this id");

user is the same value the existing "Loading doc" line and DocumentUpdatedEvent already carry.

Caveats

• "Created" means new to this server's storage: a storage reset re-logs existing docs as new on their next load.
• The server has no notion of file paths (those live inside folder docs, which it treats as opaque), so investigations still resolve path -> doc id client-side, then grep server logs by id. In our zombie-file investigations the id was always in hand; the missing half was who/when, which this supplies.

Testing

• cargo check clean (one pre-existing dead-code warning elsewhere in y-sweet-core, untouched).
• Not yet deployed anywhere. We self-host and plan to run this on our own server; happy to report back with field results if useful.