Local regex filter should not depend solely on the possibly truncated API fragment

[shouze]

Parent epic: #146

Context and problem

The local regex filter in aggregate() only tests TextMatch.fragment, the truncated excerpt returned by the GitHub API. If that fragment does not cover the full portion matched by the regex, the repository is silently dropped even though the actual file matches.

Root cause

fetchAllResults() in src/api.ts already downloads the raw file content from raw.githubusercontent.com to resolve absolute line numbers, but discards it before it reaches aggregate() in src/aggregate.ts.

Solution

• Add an optional fileContent field to CodeMatch in src/types.ts.
• In fetchAllResults(), propagate the already downloaded raw content into the returned CodeMatch instead of discarding it.
• In aggregate(), when a regex filter is active, test the full file content first when available, falling back to the fragment, and recompute the displayed segments from whichever content was used for the match.
• No new network calls, reuse only content already fetched.

Acceptance criteria

• A new test in src/aggregate.test.ts covers a match whose API fragment does not contain the full text expected by the regex, but whose file content does, the match must be kept, not silently filtered out.
• Behavior is unchanged when file content is absent, falls back to fragment as today, existing tests stay green.

Definition of done

• bun test passes, including the new regression test in src/aggregate.test.ts
• bun run lint, bun run format:check pass
• bun run knip reports no unused exports after adding the optional field to types.ts
• bun run build.ts compiles

Files

• src/types.ts
• src/api.ts
• src/aggregate.ts
• src/aggregate.test.ts