Spike: alternative approach for item-level Photos sizing

[tomekmakuch]

Problem

gsa scan --photos currently can't do item-level sizing. mediaItems.list returns 403 Forbidden — Google restricts this endpoint (2025 policy change) to app-created content only, for OAuth clients that haven't completed Google's additional access verification review. Our gsa-cli client is in Testing mode and won't pass that review as a personal-use tool. Right now, gsa report falls back to estimating Photos usage via quota math (Used − Drive − Gmail), which is directionally useful but gives no per-item breakdown (largest files/videos, etc.) the way Drive and Gmail scans do.

Spike goal

Timebox research into whether item-level Photos data is achievable another way, without going through Google's formal app verification process. Two candidates to evaluate:

1. Photos Picker API — Google's newer, non-deprecated way to access library content. Needs research into whether it can enumerate/size a whole library programmatically or whether it's inherently a user-driven picker flow (which may not fit gsa's batch-scan model).
2. Google Takeout export parsing — have the user export their Photos library via Takeout, then have gsa parse the exported files/metadata locally for real per-item sizes. No API restriction since it's not a live API call, but it's a manual/offline step and takeout can take a while to generate for large libraries.

Deliverable

A short writeup (or a couple of throwaway prototype scripts) answering: is either approach viable, and if so, which is worth building into a proper gsa command.

Context

Found and discussed in a debugging session — see CLAUDE.md Known Issues section for related Photos scanning notes.