## Why
A requirements denial on a custom `codex_apps` registration could block the trusted hosted Apps replacement. Requirements filtering also lost whether a server had been explicitly disabled, which must remain effective across runtime overlays.
## What changed
- Track explicit disables separately from requirements denials, retaining the requirement source across catalog rebuilds and server materialization.
- Allow trusted host-owned Apps to bypass a previous registration's requirements denial while preserving explicit disables and blocking later custom replacements.
- Preserve combined explicit and requirements disables during repeated filtering, and reject those servers when preparing standalone MCP login HTTP clients.
## Testing
Extend regression coverage for hosted Apps replacements, later custom replacements, cloud catalog refreshes, repeated requirements filtering, and standalone login rejection.
GitOrigin-RevId: 736a13c40fbf7436b4d0682f70c335f33f45962f
Matthew Zeng
cb2581dae8