feat(index): add opt-in discovery resource limits

[liuchong]

Related to #1347.

Problem

Indexing accepts whatever a repository contains. A tree carrying a vendored monorepo, a generated dump, or a runaway build directory is discovered in full, and the first sign of trouble is a host under memory pressure with nothing that attributes it to indexing. There is currently no way for an operator to say "not larger than this".

What this changes

Two opt-in limits, evaluated during discovery against accepted source files only, so ignored and excluded paths never count against an operator's budget:

Key	Meaning
index_max_files	Maximum number of accepted source files
index_max_source_mb	Maximum total size of accepted source files

Both default to off; without configuration this PR changes no behaviour.

Crossing a limit fails the whole attempt with a structured resource_limit_exceeded result naming the resource, the observed value and the limit. No partial graph is published, and an existing serving index keeps answering. A partial graph would be worse than no graph: it looks complete and is silently wrong.

Limits are read from the CLI-managed _config.db, not from MCP request arguments. A supervised parent replaces any caller-supplied internal policy before spawning its worker, and the worker rejects a missing or incomplete contract, so the CLI, the daemon and the supervised worker all enforce the same decision. A test pins the forged-override path.

Testing

make -f Makefile.cbm test and make -f Makefile.cbm lint-ci on macOS. New coverage: discovery counting and rejection, policy parsing and validation boundaries, worker-contract propagation and forged-override rejection, end-to-end preservation of the previously published index.

One pre-existing failure (tests/test_cli.c:6484, agent-client registry) is present on the unmodified base commit as well and is unrelated to this change.

Stack

This is the first of six PRs that replace #1348. Each is independently reviewable and mergeable in order; later ones build on earlier ones.

1. this PR — discovery limits
2. feat(index): add worker resource watchdogs #1724 — worker watchdogs
3. feat(index): enforce opt-in storage resource limits #1725 — storage limits
4. feat(index): add opt-in index resource profiles #1726 — resource profiles
5. feat(index): record and report the latest index attempt #1727 — attempt record and freshness
6. feat(mcp): warn on answers served from a failed rebuild #1728 — stale-index warning on answers

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.