Derive catalog cache keys from the filter (#207)

[deverman]

Closes #207.

The problem

CacheKey listed its fields by hand and stayed correct only because a separate shouldBypassCache expression happened to name every field the key omitted. Nothing connected the two — they agreed by inspection, not construction.

The gap was already widening:

• Expose project folder membership and root filtering in list_projects #88 nearly shipped a rootOnly omission. A cached full-catalogue page would have satisfied a request for unfiled projects only: no error, no warning, a plausible-looking answer.
• Resolve multiple project or tag names in one bounded query #171 then added searches and matchLimitPerSearch to both filters, and neither appeared in the key. That was harmless only because the batch path bypasses the cache entirely — a property nothing enforced and nobody had written down.

The change

The key is now a fingerprint of the filter's own sorted-key encoding, so any new filter field changes the identity automatically. Page limit, cursor, and requested fields stay explicit, because they are not part of the filter.

Cacheability is decided from that same encoding. "Do not cache" stays an explicit field-name list — it is a judgement about semantics (time-relative review and completion windows, live batch resolution), not something derivable — but it is now checked against the encoded filter rather than duplicated as a boolean expression that can drift from it.

Fixed while here: the tags path consulted the cache conditionally but wrote to it unconditionally, so an uncacheable tag result would still have been stored.

Tests

Existing key-separation tests are preserved and migrated rather than replaced — they pin real behaviour and all still pass. Added:

• projectCacheKeySeparatesRootOnly — the Expose project folder membership and root filtering in list_projects #88 near-miss, now structurally impossible
• projectCacheKeySeparatesBatchSearches / tagCacheKeySeparatesBatchSearches — the Resolve multiple project or tag names in one bounded query #171 fields the old key never saw
• anyFieldChangeChangesTheFingerprint — the invariant itself, across five distinct fields
• cacheability coverage for review, completion, and batch filters
• absentFieldsDoNotCountAsPresent — a nil field must not encode, or every filter would look uncacheable

One honest note on the acceptance criteria: the issue asked for a test that fails when a filter gains a field the derivation cannot see. That test cannot be written directly, because derivation sees every field by construction — which is the point. The invariant is covered instead by asserting that representative field changes each alter the fingerprint.

Validation

Impact: query. 345 tests pass; all semantic gates pass. Verified live that a rootOnly query and an unscoped query return different result sets (73 vs 150 items) with no cross-contamination.

[deverman]

Closing unmerged. This fixed no reachable bug: the rootOnly gap was already fixed in #88 with a regression test, and the batch path bypasses the cache entirely, so the searches omission and the unconditional tags write were both unreachable. 233 lines for no user-visible benefit is not a good trade, and the unwritable acceptance criterion was a signal the issue was mis-specified rather than something to work around.