Modularize the options menu catalog and handlers

Replace the monolithic options catalog and presenter-specific display/graphics wiring with explicitly registered category modules. Approved scope: - Give each options category its own class and source file containing its metadata and behavior. - Add an explicit registry that validates category ordering and unique category/setting IDs. - Keep generic layout, navigation, search, and control creation in the presenter. - Move display and graphics binding/refresh/apply/default/discard/update behavior into their category modules. - Keep currently unavailable categories declarative and behavior-free. - Avoid reflection-based discovery; compose modules explicitly at the application boundary. - Preserve current category order, search behavior, UI presentation, and display/graphics behavior. Acceptance criteria: - Each category is implemented in its own module and registered explicitly. - The presenter contains no display- or graphics-specific setting IDs or model logic. - Registry validation rejects duplicate category and setting IDs. - Existing category order, search, presentation, and display/graphics behavior are preserved. - Focused options tests pass when a .NET SDK is available. Validation blocker: this environment has no `dotnet` executable or installed SDK. Static validation confirms all 282 existing setting definitions were preserved with unique IDs across the twelve modules, but compilation and focused tests remain outstanding.