Add attachment garbage collection sweep

[cuibonobo]

Summary

Closes #64.

Attachment bytes were only ever removed by an explicit deleteAttachment(fileId) call — normal app flows delete records, and nothing noticed when the last record referencing a file went away. This adds an explicit, owner-invoked sweep to find and remove those orphans.

• Stack.collectAttachmentGarbage(opts?) / ScopedStack.collectAttachmentGarbage(opts?) (owner-only): collects attachment bytes no longer reachable from any record — live or soft-deleted — via an attachment Association or a file-ref content field (file-ref field kind: content-held file references are invisible to the reference checks the spec says exist #63). A soft-deleted record is recoverable via undelete() and must find its attachments intact, so it still counts as a reference.
• _attachment@1 metadata records never themselves count as references (else nothing would ever be garbage), but a file's newest metadata record — or, for bare bytes with none, the blob's own storage timestamp — must be older than graceMs (default 24h) to be collected. This protects the legitimate upload-then-associate window.
• Deletion goes through deleteAttachment() itself, so its usual conflict check runs once more per file at delete time; a file that races (referenced again, or already gone) is skipped, not treated as a sweep failure — the sweep always completes and reports what it actually collected.
• dryRun: true computes and returns what would be deleted without deleting anything.
• New optional StackBlobAdapter.listFiles() capability (same "optional method, checked for truthiness" pattern as deleteUnreferencedAttachmentRecords), implemented in blob-adapter-disk and MemoryAdapter, wired through LocalAdapter. This is what finds bare-bytes orphans — bytes with zero metadata records at all, left by a putAttachment() that stored bytes but crashed before writing metadata — which are otherwise undiscoverable. An adapter without it still gets full protection for the common case.

Two latent bugs fixed along the way

• deleteAttachment()'s non-atomic fallback path didn't pass includeDeleted on its reference check or its metadata-cleanup scan, so a soft-deleted (recoverable) record's attachment reference didn't block deletion, and a soft-deleted metadata record was never cleaned up. The atomic adapter path already got this right (it doesn't filter on deleted_at at all); the fallback now matches.
• combineAdapters() silently dropped optional adapter capabilities (deleteUnreferencedAttachmentRecords, and now listFiles) instead of forwarding them when the underlying part actually implements them — meaning a record adapter that supports the atomic delete path lost that capability the moment it was composed via combineAdapters().

Test plan

• packages/core/tests/stack.test.ts — collectAttachmentGarbage: basic collection, live/soft-deleted/file-ref reference protection, default and explicit grace period, reclaimedBytes accounting, dryRun, bare-bytes orphan collection via listFiles(), graceful behavior when listFiles() is absent, and a simulated delete-time race that's skipped without aborting the sweep. Plus regression tests for the two includeDeleted fixes.
• packages/core/tests/scoped-stack.test.ts — owner-only gating (owner/non-owner/anonymous).
• packages/core/tests/combine.test.ts (new) — optional-capability forwarding round-trips exactly (present when implemented, absent when not), plus basic composition and lifecycle behavior.
• packages/blob-adapter-disk/tests/blob.test.ts — listFiles() enumeration, sizes, timestamps, post-delete removal, ignoring stray non-fileId files.
• packages/adapter-local/tests/local.test.ts — listFiles() through the real combined adapter.
• Full monorepo build, typecheck, lint, and test suite (627 tests) pass.

🤖 Generated with Claude Code

---

Generated by Claude Code