storage: parallelize detectAssetFiles slug lookups (from PR #55 Copilot review)

[arndvs]

Parent PR: #55
Source comment: #55 (comment)
File: lib/cast/server/storage.ts:119
Confidence: 40 = 50 +20 specific +15 ≤10 lines +15 coverage −25 vague −15 semantics −20 shared

Interpretation

detectAssetFiles() awaits each slug sequentially. With the Azure adapter this means serial network round-trips — Promise.all (or a concurrency-limited variant) would reduce latency proportionally to the slug count.

Proposed approach

• Replace the for...of + await loop with Promise.all(slugs.map(...)) or use a concurrency limiter (e.g. p-limit) to cap at ~5 parallel lookups
• Verify error behavior: currently a single failed lookup throws and aborts all remaining slugs — decide whether partial results are acceptable

Blockers / questions

• The local FS adapter does fs.access per extension (up to 4 per slug) — is the overhead even measurable for typical slug lists (≤20)?
• Azure adapter isn't in production yet — this is speculative optimization

Context for shft

Files to read:

• lib/cast/server/storage.ts — detectAssetFiles and findLocalAsset functions
• app/api/detected-assets/route.ts — sole caller, to understand typical slug list sizes

Acceptance criteria:

• detectAssetFiles runs lookups concurrently (or concurrency-limited)
• Existing detected-assets tests still pass
• No change to the return type or error contract

Feedback loops:

• pnpm test tests/outputs-route.test.ts
• pnpm typecheck