fix(service-storage): stamp sys_upload_session.organization_id from the acting session (#13180)

* fix(service-storage): stamp sys_upload_session.organization_id from the acting session (#12928)

WIP checkpoint before the build/test lap.

* chore: record the new sys_upload_session engine doubles in the pinned ledger (#12928)

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: Elon Musk

.changeset/upload-session-organization-stamp.md

@@ -0,0 +1,36 @@
+---
+"@objectstack/service-storage": patch
+---
+
+fix(service-storage): stamp `sys_upload_session.organization_id` from the acting session (#12928)
+
+`StorageMetadataStore.createSession` inserted into `sys_upload_session` with no
+execution context, so the SQL driver's `injectTenantOnInsert` had no `tenantId`
+to stamp from and every chunked-upload session row landed with
+`organization_id` NULL — on a tenancy-ENABLED object (the declaration carries no
+`tenancy` key, so `applySystemFields` provisions the column unconditionally).
+This is the `sys_upload_session` sibling of the `sys_file` gap fixed in #12745,
+and the chunked-upload door already held the value: it threads the identical
+`session?.organizationId` into the `createFile` immediately above.
+
+`createSession` now takes the same optional `StorageWriteContext` as
+`createFile` and hands the engine `{ context: { tenantId } }`, so the platform's
+existing insert-side chokepoint decides the rest — whether the object has a
+tenant column at all, and whether an explicit value on the row wins. A caller
+with no organization passes no options and the row lands unstamped exactly as
+before.
+
+Maintainer ruling 2026-08-29, verbatim and untranslated: 「同意」 — forward stamp
+only. There is deliberately **no backfill**: rows already NULL age out through
+this object's own ADR-0057 TTL sweep. That premise is verified rather than
+assumed — `sys-upload-session-ttl-sweep.test.ts` drives the shipped declaration
+through the real `LifecycleService` against live SQL and pins that an expired
+NULL-organization row is reaped, that a stamped row is reaped by the same
+sweep, that a live session survives it, and that a run with no declaration reaps
+nothing.
+
+Why an unstamped row mattered even without a cross-tenant read: both walled
+Layer 0 predicates are exclusive (`{ organization_id: <id> }` under `isolated`,
+`{ $in: [...] }` under `group`), and neither matches NULL — so on a walled
+deployment an unstamped session row was invisible to its own tenant, the same
+silent-empty class `sys_api_key` was renamed to avoid.

packages/services/service-storage/src/metadata-store.ts

@@ -50,7 +50,8 @@ export interface FileRecord {
 }
 
 /**
- * The acting session's organization, threaded into a `sys_file` write (#12745).
+ * The acting session's organization, threaded into a `sys_file` write (#12745)
+ * or a `sys_upload_session` write (#12928).
  *
  * ## Why a context and not a column on the payload
  *
@@ -125,6 +126,21 @@ export interface UploadSessionRecord {
   started_at?: string;
   expires_at?: string;
   updated_at?: string;
+  /**
+   * The registry-injected tenant column (#12928) — the `sys_upload_session`
+   * sibling of the `sys_file` declaration above.
+   *
+   * `sys_upload_session` declares no `tenancy` key either, so
+   * `isTenancyDisabled()` reads `false` and `applySystemFields` provisions
+   * `organization_id` on every install, walled deployment or not.
+   *
+   * Same division of labour as {@link FileRecord.organization_id}: the store
+   * does NOT put this in the engine payload (see {@link StorageWriteContext}),
+   * and it is declared here because the column is real — a caller may read it
+   * back off a row, an admin cross-organization write may set it explicitly,
+   * and the engine-absent stand-in records it.
+   */
+  organization_id?: string | null;
 }
 
 /** The `IDataEngine` operations this store issues. */
@@ -331,7 +347,29 @@ export class StorageMetadataStore {
   // Upload sessions
   // ---------------------------------------------------------------------------
 
-  async createSession(rec: UploadSessionRecord): Promise<UploadSessionRecord> {
+  /**
+   * Insert one `sys_upload_session` row.
+   *
+   * `context` carries the acting organization (#12928). It is the same channel,
+   * the same chokepoint and the same reasoning as {@link createFile} (#12745):
+   * with it the insert reaches the engine as `{ context: { tenantId } }`, which
+   * is how `sys_upload_session.organization_id` gets written at all — see
+   * {@link StorageWriteContext} for the chain and for why the column is not
+   * stamped onto the payload here. Without it the call behaves exactly as it
+   * did before: the row lands unstamped.
+   *
+   * ⚠️ Ruled scope (maintainer, 2026-08-29, verbatim and untranslated: 「同意」):
+   * FORWARD STAMP ONLY. Rows that are already NULL are deliberately not
+   * repaired — they age out through this object's own ADR-0057 TTL sweep
+   * (`lifecycle.ttl`, keyed on `expires_at`). That premise is not assumed here:
+   * `sys-upload-session-ttl-sweep.test.ts` drives the real declaration through
+   * the real Reaper against live SQL, because if the sweep were dead the
+   * no-backfill half of the ruling would fall with it.
+   */
+  async createSession(
+    rec: UploadSessionRecord,
+    context?: StorageWriteContext,
+  ): Promise<UploadSessionRecord> {
     const now = new Date().toISOString();
     const full: UploadSessionRecord = {
       uploaded_chunks: 0,
@@ -341,12 +379,20 @@ export class StorageMetadataStore {
       updated_at: now,
       ...rec,
     };
+    const options = writeOptionsFor(context);
     if (!this.engine) {
-      this.sessions.set(full.id, full);
-      return full;
+      // Mirrors `createFile`'s stand-in exactly: no schema to ask, so it
+      // records what it was told, and an explicit value on the record wins
+      // just as `injectTenantOnInsert` lets it.
+      const stamped: UploadSessionRecord =
+        options && full.organization_id == null
+          ? { ...full, organization_id: options.context.tenantId }
+          : full;
+      this.sessions.set(stamped.id, stamped);
+      return stamped;
     }
     await this.engineOp('sys_upload_session', 'insert', SESSION_INSERT_CONSEQUENCE, (engine) =>
-      engine.insert('sys_upload_session', full),
+      engine.insert('sys_upload_session', full, options),
     );
     return full;
   }

packages/services/service-storage/src/storage-routes.ts

@@ -20,11 +20,13 @@ export type FileReadVerdict = 'allow' | 'deny' | 'unauthenticated';
  *
  * `organizationId` is the session's ACTIVE organization — the scope the upload
  * is happening in, and the value threaded into `createFile` so the new
- * `sys_file` row is stamped rather than landing NULL. It is optional in both
- * directions on purpose: a resolver that only knows the user (every
- * pre-#12745 implementation, and every single-tenant deployment) keeps
- * type-checking and keeps working, and a session with no active organization
- * resolves to `undefined` rather than to a guess.
+ * `sys_file` row is stamped rather than landing NULL, and (since #12928) into
+ * `createSession` so the chunked door's `sys_upload_session` row is stamped
+ * for the same reason. It is optional in both directions on purpose: a
+ * resolver that only knows the user (every pre-#12745 implementation, and
+ * every single-tenant deployment) keeps type-checking and keeps working, and a
+ * session with no active organization resolves to `undefined` rather than to a
+ * guess.
  */
 export interface StorageUploadSession {
   userId?: string;
@@ -478,23 +480,31 @@ export function registerStorageRoutes(
       const resumeToken = randomUUID();
       const expiresAt = new Date(Date.now() + sessionTtl * 1000).toISOString();
 
-      await store.createSession({
-        id: uploadId,
-        file_id: fileId,
-        key,
-        filename,
-        mime_type: mimeType,
-        total_size: totalSize,
-        chunk_size: chunkSize,
-        total_chunks: totalChunks,
-        resume_token: resumeToken,
-        backend_upload_id: backendUploadId,
-        scope: scope ?? 'user',
-        bucket,
-        metadata: metadata ? JSON.stringify(metadata) : undefined,
-        status: 'in_progress',
-        expires_at: expiresAt,
-      });
+      // The session row is stamped from the SAME session value the
+      // `createFile` above already threads (#12928). `sys_upload_session` is a
+      // tenancy-enabled object too, so an insert with no context lands
+      // `organization_id` NULL — invisible to its own tenant under a walled
+      // posture, since both walled Layer 0 predicates exclude NULL.
+      await store.createSession(
+        {
+          id: uploadId,
+          file_id: fileId,
+          key,
+          filename,
+          mime_type: mimeType,
+          total_size: totalSize,
+          chunk_size: chunkSize,
+          total_chunks: totalChunks,
+          resume_token: resumeToken,
+          backend_upload_id: backendUploadId,
+          scope: scope ?? 'user',
+          bucket,
+          metadata: metadata ? JSON.stringify(metadata) : undefined,
+          status: 'in_progress',
+          expires_at: expiresAt,
+        },
+        { organizationId: session?.organizationId },
+      );
 
       sendOk(res, {
         uploadId,