fix: bound resumable teardown, image concurrency and delivery leases

TR-RR-06. dispose() now bounds its drain with a cleanupDeadlineMs from policy
and returns the result, so a non-cooperative mutation lock or provider can no
longer make teardown unbounded and an unproved drain is reported as still
CLOSING instead of closed over. The checkpoint store stays open in that case,
because something can still write to it. An abort is admitted physical work
like an upload, so it joins the tracked set rather than being stepped over.

TR-RR-07. The verification slot belongs to the raw verifier, not the wrapper.
Releasing it when the caller's wait expired let an abandoned verification keep
running while a new one was admitted, so repeated aborts produced more
concurrent physical work than the configured cap allows. The slot is now
released only once the raw tasks settle.

TR-RR-04. A presigned byte source owns a fetch reader and a capability lease and
its port requires close(); the delivery consumer never called it. The closeable
subtype is lost in the FileByteSource projection, so a holder keeps it from the
moment the lease exists and the outermost finally closes it exactly once — on
success, validation failure, writer failure and abort alike.

check:adapter-inventory now also fails if the shared abortable-operation
primitive has no production importers. It was safe to add only once the
presigned subsystems actually migrated onto it; a gate that fails CI for a
documented, unfixed defect reports the wrong thing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

tests/unit/image-cdn-runtime.test.ts

@@ -1006,7 +1006,13 @@ describe("production image CDN runtime", () => {
     expect(abortDeadline.clearTimeout).toHaveBeenCalledOnce();
   });
 
-  it("bounds concurrent capability verification and releases the slot after abort", async () => {
+  /**
+   * TR-RR-07. The concurrency cap exists to bound *physical* verification work.
+   * Releasing the slot when the wrapper's abort resolved let an abandoned
+   * verifier keep running while a new one was admitted, so repeated aborts
+   * produced more concurrent work than the configured cap allows.
+   */
+  it("holds the verification slot until the raw verifier settles", async () => {
     const preset = imageCdnPresetReference(
       "verification-concurrency",
       "bound-image-verification-concurrency",
@@ -1018,10 +1024,13 @@ describe("production image CDN runtime", () => {
       },
     });
     let verificationAttempt = 0;
+    let releaseFirst: ((value: boolean) => void) | undefined;
     const verify = vi.fn(() => {
       verificationAttempt += 1;
       return verificationAttempt === 1
-        ? new Promise<boolean>(() => undefined)
+        ? new Promise<boolean>((resolve) => {
+            releaseFirst = resolve;
+          })
         : Promise.resolve(true);
     });
     const runtime = createImageCdnRuntime({
@@ -1054,9 +1063,24 @@ describe("production image CDN runtime", () => {
       ok: false,
       error: { code: "ABORTED" },
     });
+
+    // The caller's wait ended, but the raw verifier has not. Admitting a second
+    // one here would put two physical verifications under a cap of one.
     await expect(
       runtime.assets.acceptBackendIssued(issued),
-    ).resolves.toMatchObject({ ok: true });
+    ).resolves.toMatchObject({
+      ok: false,
+      error: { code: "LIMIT_EXCEEDED" },
+    });
+    expect(verify).toHaveBeenCalledOnce();
+
+    // Once the raw verifier settles the slot is free again.
+    releaseFirst?.(true);
+    await vi.waitFor(async () => {
+      await expect(
+        runtime.assets.acceptBackendIssued(issued),
+      ).resolves.toMatchObject({ ok: true });
+    });
     expect(verify).toHaveBeenCalledTimes(2);
   });