feat: EHR search table stakes (_has, uri, include wildcards, 2-hop chains)

[degoke]

Implement the search features EHR apps actually send, instead of Lucene or _filter first. This is item 2 of the HAPI-inspired build list (REST table stakes is PR #50).

What landed

_has reverse chaining. Patient?_has:Observation:subject:code=8867-4 uses the existing search parser/planner/executor. One extra nested _has is allowed; deeper nesting is still ErrUnsupportedFeature.

uri SearchParameters. Registry uri params are indexed as uri.* (stored on the string tables). Exact match plus :below / :above hierarchy modifiers.

Include wildcards. _include=Observation:*, _include=*:*, _revinclude=Observation:*, and _revinclude=*:* expand at resolve time to the matching reference SearchParameters. Source * on _include means the search type (*:general-practitioner on Patient → Patient:general-practitioner). Typed includes _include=Observation:subject:Patient work. Recursive _include:iterate is still rejected.

Two-hop chains. Observation?subject.organization.name=Acme parses as a nested ChainClause, walks the inner match first, then the outer reference. Depth > 2 stays unsupported.

Execution notes

• _has and two-hop chains run on SearchQueryExecutor (SQLite/mem + Postgres).
• Wildcard _include / _revinclude still need SearchAdvancedExecutor (Postgres-first), same as existing includes.
• Wildcard expansion skips reference params whose target types are not enabled, rather than failing the whole query.

Tests

• Parser/resolve/execute coverage in pkg/search/ehr_search_test.go
• Indexer emits uri.url for Questionnaire
• Postgres integration tests for _has, two-hop, url:below, and Observation:* (skipped without Postgres)