docs(adr-0057): reap guards amendment + attachments changeset (#2755)

Document the LifecycleService reap-guard seam (domain re-verification +
external-resource reclaim) as an ADR-0057 amendment, with sys_file as the
first consumer, and add the release changeset for the framework packages.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0187NT3Qer9oep5dCRb9b8Lt

Author: claude

.changeset/attachments-2755-followups.md

@@ -0,0 +1,38 @@
+---
+'@objectstack/objectql': minor
+'@objectstack/service-storage': minor
+'@objectstack/platform-objects': minor
+'@objectstack/verify': minor
+'@objectstack/rest': patch
+---
+
+feat(attachments): sys_file orphan lifecycle + parent-derived attachment access (#2755)
+
+**Orphan lifecycle (ADR-0057).** Deleting a `sys_attachment` join row used to
+orphan the backing `sys_file` row and its storage bytes forever. `sys_file`
+now declares a lifecycle (`ttl 30d` on a new `deleted_at` tombstone for
+orphans; `retention 7d onlyWhen status=pending` for abandoned uploads), the
+storage plugin's new hooks tombstone a file when its LAST join row is deleted
+(attachments scope only — `Field.file`/`Field.image`/avatar scopes are never
+touched) and un-tombstone on re-attach, and a new LifecycleService **reap
+guard** seam (`registerReapGuard`) re-verifies zero references at sweep time
+and deletes the storage bytes before confirming each row reap. A guarded
+object is never blind-deleted; an erroring guard fails safe (rows retained).
+
+**Attachment access (ADR-0049, Salesforce parent-derived semantics).**
+`sys_attachment` create now requires caller READ visibility of the parent
+record (403 `ATTACHMENT_PARENT_ACCESS`) and server-stamps `uploaded_by` from
+the session (client value ignored); delete requires uploader-or-parent-editor
+(403 `ATTACHMENT_DELETE_DENIED`). The storage upload routes require an
+authenticated session when an auth service is wired (401 `AUTH_REQUIRED`;
+bare kernels stay open) and stamp `owner_id` on new files.
+
+**REMOVED — `sys_attachment.share_type` / `sys_attachment.visibility`.**
+Both fields were modeled in v1 with zero runtime consumers (ADR-0049
+parsed-but-unenforced). There is no replacement key: attachment access is
+derived from the parent record by the hooks above. Writers of these fields
+should simply stop sending them (unknown-field validation will reject them);
+existing DB columns are left as unmanaged leftovers, no migration needed.
+
+`@objectstack/verify` gains `BootOptions.extraPlugins` for booting optional
+service pairs (e.g. storage + audit) in dogfood fixtures.

docs/adr/0057-system-data-lifecycle-and-retention.md

@@ -170,6 +170,28 @@ registered ⇒ rows are retained (today's behavior), reported as
 `archive-pending` — a compliance ledger cannot be destroyed by declaring a
 lifecycle.
 
+#### Amendment (#2755): reap guards — domain re-verification + external-resource reclaim
+
+Some reapable rows are pointers to state the Reaper cannot see: `sys_file`
+rows reference storage bytes (disk/S3), and a tombstoned orphan may have
+regained `sys_attachment` references since it was marked. For these, a plugin
+may register a **reap guard** at runtime
+(`lifecycle.registerReapGuard(object, guard)`): the Reaper fetches candidate
+rows in batches, the guard confirms each id — performing external cleanup
+(byte deletion) and sweep-time re-verification first — or vetoes it (kept,
+retried next sweep). Rules:
+
+- A guarded object is **never blind-deleted**: an erroring guard fails safe
+  (rows retained), and an engine without row reads skips the object
+  (`reap-guard-unsupported`) rather than degrading to a blind delete.
+- Guards are runtime wiring, not spec surface — detection and scheduling stay
+  inside the single platform sweep (no bespoke sweepers, per the alternatives
+  below); the guard is a domain callback, not a scheduler.
+- First consumer: `sys_file` (service-storage) — attachment orphans are
+  tombstoned by hooks when their last `sys_attachment` reference is deleted,
+  reaped `30d` later by TTL with byte reclaim, with zero-reference
+  re-verification at sweep time; abandoned `pending` uploads reap after `7d`.
+
 ### 3.4 Reclaim — driver space hygiene
 
 SQLite driver defaults to `auto_vacuum=INCREMENTAL` (shipped P0); the Reaper