Org-scoped coverage via org-owned tokens with coverage stamping

[gkanitz]

Parent

#1

What to build

Org-scoped reports: one run covers the subject's activity across all repositories visible to an org-owned token, not just one repo. Support GitHub App installation tokens (created by the org via the app-manifest flow) alongside plain tokens. Enumerate accessible repos, aggregate the subject's activity across them, and stamp the coverage block with the full covered-repo list, time window, and token scope so omissions are visible to any reader ("covers N repos of org X, window Y–Z").

Token acquisition stays a pluggable concern: the core consumes "a token"; the CLI/wrappers decide where it comes from.

Acceptance criteria

• A single run with an org-scoped token produces one report aggregating activity across all visible repos
• Coverage stamp lists every covered repo, the time window, and the token scope class
• GitHub App installation token flow works end-to-end (documented manual test against a real org is acceptable)
• Adapter fixtures cover multi-repo enumeration and aggregation; metrics tests prove cross-repo aggregation (e.g., reviews in repo A + repo B sum correctly)

Parallel-work contract

This issue runs in parallel with #3, #4, #6. Territory rules (reviewer must enforce):

• Owns: repo-enumeration and token/auth plumbing as new files in the GitHub adapter and CLI (GitHub App installation tokens, scope detection), cross-repo aggregation wiring, and the coverage sub-struct of the report schema.
• Must not modify ActivitySet (that right belongs to Full GitHub collaboration metrics (reviews, comments, merge timing, rework) #3 this wave) or the adapter's activity-fetch files — enumeration and auth live in their own files.
• Must not touch: metrics package files, the collaboration/cadence/verification sub-structs, CI wrapper YAML.
• Shared files (schema root, CLI flag wiring): additive-only changes.

Blocked by

• Walking skeleton: GitHub repo → metrics → schema-v0 report → HTML via CLI #2