fix(file-picker): apply imageOnly filtering server-side on the default list path

[pedrofrxncx]

Follows #6087 (month-shard probing) in apps/api/src/file-storage/file-config-s3.ts — while reading it for post-merge hardening I found listObjects's imageOnly param was only honored on the search scan path (searchObjects / matchScanPage); the default (no-search) path — the month-shard probes, the broad fallback, and the cursor page via finalize() — accepted imageOnly and silently ignored it, returning every key type regardless.

Why it matters: the web file-picker (file-picker-dialog.tsx) re-filters client-side with its own isImageKey, so this wasn't a wrong-result bug, but it meant an image-only picker's page of target keys could be mostly non-images that the client immediately discards — undercounting real images per page and forcing extra "Load more" round trips on buckets with a low image ratio. The doc comment on isImageKey already states server-side filtering matters "so the scan doesn't waste budget on rows the client throws away" — that reasoning applies equally to the default path, it just wasn't wired up there.

Fix: apply the same isImageKey filter used in matchScanPage to all three non-search code paths (month-shard merge, broad fallback merge, and finalize() for cursor pages), so an image-only request actually returns up to target images per page instead of relying entirely on client-side discarding.

Reviewer check: bun test apps/api/src/file-storage/file-config-s3.test.ts (27 pass, unchanged — listObjects itself isn't unit-tested per this file's existing pattern, since it requires a live/mocked S3Client; the filtering logic is the same isImageKey predicate already covered by the isImageKey and matchScanPage describe blocks).

Locally ran: bun run fmt, cd apps/api && bunx tsc --noEmit (clean), bunx oxlint apps/api/src/file-storage/file-config-s3.ts (0 warnings/errors), and the targeted test file above. Full CI validates the rest.

Net diff: +7/-1, one file, one concern.

---

Summary by cubic

Applies server-side imageOnly filtering on the default listObjects path so image-only requests return up to target images across all code paths. Previously, imageOnly was only honored on the search scan path; the default path ignored it and returned mixed keys, causing underfilled image pages and extra “Load more” requests.

Review notes

• Applies the existing isImageKey predicate to month-shard merges, the broad fallback, and finalize() cursor pages.
• No change when imageOnly is false; when true, non-image keys are skipped and target now counts images rather than all keys.
• No API changes; expect fewer wasted S3 results and fewer client round trips for image-only pickers.

^{Written for commit 54c6585. Summary will update on new commits.}