search: _tag, _profile and _security filters are silently dropped — even under Prefer: handling=strict — and the self link claims they were applied

[angela-helios]

Found by #448 sweep iteration 3 (SQLite, Synthea data, 27 patients).

GET /Patient?_tag=http://example.org/none       → 200, total 27 (all patients)
GET /Patient?_profile=http://example.org/none   → 200, total 27
GET /Patient?_security=http://example.org/none  → 200, total 27
GET /Patient?_tag=… with Prefer: handling=strict → still 200, still 27

Two problems compounding:

1. The three meta-level token parameters are not implemented, and the search drops them silently instead of applying them — the response returns everything. For _security (labels used in access-control workflows) a silently unapplied filter is the worst possible failure mode.
2. The searchset's self link echoes the parameter back (…/Patient?_tag=http%3A%2F%2Fexample.org%2Fnone), which per the spec is the server's statement of which parameters it actually processed — so the client is actively told the filter worked.

Per FHIR search, unsupported parameters may be ignored only in lenient handling and only if reported (dropped from the self link, ideally with an OperationOutcome); under Prefer: handling=strict they SHALL be an error. Either implement the three (they are ordinary token indexes over meta.tag / meta.profile / meta.security) or reject/report them honestly.

Part of the #448 sanity pass, iteration 3.