[Ticket]: Spike - Microsoft Copilot (M365) as a telemetry source; verify its API before the RFC-0003 row is trusted

### Type

Feature

### Summary

Microsoft Copilot (M365) is a telemetry source this platform will need and the only row in
RFC-0003's matrix with no ticket anywhere. It is a **distinct product from Microsoft Foundry**
(RFC-0002) and from GitHub Copilot — different tenancy model, different API, different data.

Filing it so the matrix is complete. This ticket asks for a **spike first**: its API surface
has not been verified, and RFC-0003's matrix row for it is provisional until someone has.

### Intent

RFC-0003 §9 makes source enumeration the gate on implementation — a source declares its
matrix row before its code is written. M365 Copilot currently has a row asserted from
reasoning rather than from a verified API, which is exactly the state the gate exists to
prevent. Either the row gets evidence behind it, or the source is explicitly declared out of
scope; leaving it as an unverified row is the one outcome the taxonomy should not tolerate.

### Source of truth (links)

- RFC-0003 §2 (matrix — the M365 row) and §8 (gaps: "no ticket in this repo or any other")
- ADR-0013 — the declaration gate this ticket satisfies
- #157 — the PR carrying both

### Current Behavior

Not ingested. Not filed. Its matrix row reads `pull cron · day · tenant-scoped · C · seats`,
asserted rather than verified.

### Expected Behavior

Either a verified matrix row and a scoped connector, or a recorded decision that M365 Copilot
is out of scope with the reason.

### Acceptance Criteria

1. The reporting API surface is identified and its shape recorded: available endpoints, grain,
whether per-user detail exists or only tenant aggregates, retention/backfill window, rate
limits.
2. The **identity question** is answered: what identifier does it return, and can that be
resolved to the same engineer that `IdentityMap` already resolves a GitHub login and an
OIDC subject to? A source that cannot be tied to a person is a tenant-level gauge, not a
governance source, and should be scoped as such.
3. The RFC-0003 row is corrected against what was found, including cost units.
4. The credential required is identified, and its blast radius stated — pattern C means a
long-lived third-party admin credential at rest.
5. Either a connector is scoped as a follow-up story, or an out-of-scope decision is recorded.

### Out of Scope

- Building the connector. This is the spike that decides whether and how.
- Microsoft Foundry (RFC-0002) and GitHub Copilot — different sources, already covered.

### Technical Context

Pattern C, so it needs the machine-to-machine grant that does not exist yet
(`lightbridge-authz`#534) *and* a tenant-scoped Microsoft admin credential. Two blockers, one
of them outside this repo.

Grain matters here: if it returns only tenant-level daily aggregates, it belongs with the
day-grain tables and **must not** be joined to request-grain data. Mixing those is the
double-counting defect ADR-0013 invariant 5 exists to prevent.

Note the day-grain tables are Copilot-named today (`copilot_org_daily` and siblings) and
RFC-0003 §3 already calls for generalising them by source. M365 would be the second occupant,
so this spike is a good forcing function for that migration — cheaper now than after four
more land.

### Risks

- The reporting API may not expose per-user detail at all, which would make this a tenant
gauge rather than a governance source. Worth knowing before anyone promises a per-engineer
breakdown that includes it.
- Licensing and tenancy differ from GitHub Copilot; assuming symmetry with RFC-0001 is the
likely mistake.
- ⚠️ Everything above about the API is **unverified**. It is the question, not the answer.

### Test Plan

Spike output is a written finding, not code. It should say plainly if the answer is "not
feasible" or "not worth it" — an accurately-reported dead end is worth more than a connector
built on an assumed API shape.