Enable _list search resolution securely with Medino

**Describe the bug**
`ListSearchPipeBehavior` was not intentionally registered before the Medino migration. Medino assembly scanning can register it automatically, changing behavior as part of PR #5235. When enabled without an authorization behavior running first, `_list` resolution can short-circuit the normal search handler and bypass search authorization.

PR #5235 should preserve migration parity by suppressing the accidentally scanned `ListSearchPipeBehavior`. Secure `_list` enablement should be implemented and reviewed separately rather than expanding the migration PR.

**FHIR Version?**
Stu3/R4/R5

**Data provider?**
CosmosDB/SQL Server

**To Reproduce**
Steps to reproduce the behavior:
1. Register Medino handlers and pipeline behaviors through assembly scanning.
2. Submit a search request using the `_list` parameter where list resolution returns without invoking the normal search handler.
3. Observe that handler-level search authorization is not reached unless authorization is enforced before list resolution.

**Expected behavior**
The Medino migration does not activate previously unregistered `_list` resolution behavior. A focused follow-up change intentionally enables `_list` resolution only with authorization ordered before it, with security and integration tests covering short-circuit paths.

**Actual behavior**
Medino scanning can activate `ListSearchPipeBehavior` unintentionally. Its short-circuit path can return a response before the normal search handler performs authorization.

Start by reviewing PR #5235 and the Medino assembly-scanning registration of ListSearchPipeBehavior. Trace the _list short-circuit path and authorization ordering, then add focused security and integration tests covering cases where list resolution returns before the normal search handler. Done means _list resolution is intentionally enabled only after authorization and the migration does not activate it accidentally.

Written by the indexing model from the issue text.