Add property-based tests for core.Resolve using pgregory.net/rapid

[gregology]

Closes #20

The project docs (docs/testing.md, AGENTS.yaml decisions) explicitly call for property-based tests on core.Resolve using pgregory.net/rapid, but they never got written. The existing table-driven tests cover known scenarios well — the gap is the combinatorial stuff you don't think to enumerate by hand. Weird glob interactions, deep nesting, empty match lists paired with non-empty excludes, that kind of thing.

This adds the five invariant tests that were already documented:

• Resolve never panics for any valid input (random directory trees, random AGENTS.yaml content, random request params)
• Child context merges with parent — never overrides it
• Exclude patterns always win over match patterns
• on: edit entries stay out of ActionRead results
• Parent entries come before child entries in output ordering

Each test uses rapid.Check with generated inputs so we're exploring the input space rather than just checking the cases we thought of.

Why rapid specifically

The docs already prescribed it. But even if they hadn't — rapid is a good fit here because it integrates directly with testing.T, does automatic shrinking on failures, and doesn't need a separate test runner. The alternative would be gopter, which has a heavier API and less idiomatic Go integration. testing/quick from stdlib was another option but it's frozen and lacks shrinking.

Why these five invariants and not more

These are the properties that matter for correctness of the resolution engine. Other things (like "valid YAML always parses") are stdlib behavior. The project's own testing guidelines say to test at public API boundaries and avoid testing private functions or Go stdlib behavior, so I stuck to that.

Resolves #20