Inventory repository instruction files separately from contribution findings

Repositories increasingly include committed files that provide coding-agent instructions. Examples include `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.github/copilot-instructions.md`, `.github/instructions/**/*.instructions.md`, `.cursor/rules/**/*.mdc`, `.clinerules/**`, `.windsurf/rules/**/*.md`, and `.continue/rules/**/*.md`.

Their presence does not establish that any commit involved AI. It does record that maintainers have adopted a repository-level convention for agent guidance, which can be measured across projects and over time.

Disclosure currently scans commit and text inputs. A `Finding` contributes to `AICommits`, the CLI exit status, and GitHub Action labelling. Passing instruction files through the existing `Detector` interface would make those outputs ambiguous.

Would a separate git-backed inventory fit the project? It could inspect the current tree and return neutral records such as:

```json
{
"kind": "agents_md",
"path": "docs/AGENTS.md",
"added_commit": "abc123",
"added_author_at": "2026-05-25T05:52:25Z",
"added_committer_at": "2026-05-25T05:52:25Z"
}
```

The addition fields could be optional because finding the original commit requires more history than checking current presence. A current-tree scan would remain cheap, while indexers could request history when they need adoption dates. This can stay within disclosure's git-only approach and does not require a forge API.

Start by tracing the existing Detector interface and the commit/text scanning entry points, including how Findings affect AICommits, CLI exit status, and GitHub Action labelling. Define the separate git-backed inventory boundary and its neutral record shape, then verify that instruction-file records remain independent of Finding outputs and that current-tree scanning works without forge APIs.

Written by the indexing model from the issue text.