test(webapp): delete dead authorization.test.ts, update batch e2e to match backwards-compat fix

Two CI failures on PR #3499:

1. Shard 7 — `test/authorization.test.ts` failed at module load with
   "Cannot find module '../app/services/authorization.server'". That
   module was deleted in 18e0701 (the entire `checkAuthorization`
   function went with the apiBuilder migration), but I missed the
   test file that exercised it — the earlier grep for live consumers
   only walked `app/`, not `test/`. The test was unit coverage for
   the now-deleted function; nothing else worth saving in it. Delete.

2. E2E auth — `JWT read:runs: 403 (resource type is 'batch', not 'runs')`
   was asserting the strict-match behaviour that 9f987ae deliberately
   reverted for backwards compat (batch retrieve routes wrap
   `{type: "batch", id}` in anyResource([...]) alongside `{type: "runs"}`
   so JWTs minted with read:runs against batch endpoints keep working).
   The test caught my own intentional change. Update the expectation:
   `read:runs` JWT should now pass (not be 403), and rename the test to
   reflect the new behaviour with a comment pointing at the
   backwards-compat rationale.

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

Author: matt-aitken

apps/webapp/test/auth-api.e2e.full.test.ts

@@ -1681,21 +1681,24 @@ describe("API", () => {
       expect(res.status).not.toBe(403);
     });
 
-    it("JWT read:runs: 403 (resource type is 'batch', not 'runs')", async () => {
+    it("JWT read:runs: auth passes (backwards-compat for legacy SDKs)", async () => {
       const { batchFriendlyId, apiKey, environment } = await seedRunWithBatch();
       const jwt = await generateJWT({
         secretKey: apiKey,
         payload: { pub: true, sub: environment.id, scopes: ["read:runs"] },
         expirationTime: "15m",
       });
       const res = await get(pathFor(batchFriendlyId), { Authorization: `Bearer ${jwt}` });
-      // Pre-TRI-8719 the legacy literal-match escape granted
-      // read:runs access to batch endpoints. Post-migration the
-      // resource type is strictly { type: "batch" } and read:runs
-      // doesn't match. Lock this in — if SDKs were issuing
-      // read:runs:* JWTs for batch lookups, that's a regression to
-      // catch.
-      expect(res.status).toBe(403);
+      // Pre-RBAC the batch-retrieve route's superScopes included
+      // `read:runs`, so JWTs minted with read:runs could read batches.
+      // The post-migration backwards-compat fix adds a `{type: "runs"}`
+      // element to the route's anyResource(...) list so those
+      // SDK-issued JWTs in the wild keep working — avoids a silent
+      // 401/403 regression for callers we never told to switch scopes.
+      // Per-id `read:batch:<id>` and type-level `read:batch` still
+      // grant via the route's first resource element.
+      expect(res.status).not.toBe(401);
+      expect(res.status).not.toBe(403);
     });
 
     it("JWT read:all super-scope: auth passes", async () => {