Isolate lazy exports and platform compatibility attribute access

Parent tracking issues: #4903 and #4905

Desired Behavior

Intentional runtime feature detection should be isolated in small typed compatibility helpers, while package exports should use explicit import maps or direct exports. Core SDK modules should not contain scattered dynamic attribute probes for lazy exports, platform constants, rich stdout wrappers, response status, optional file APIs, tracing metadata, or type names.

Where Python module-level __getattr__ is required for import-cycle or compatibility reasons, use an explicit name-to-object loader map and keep any unavoidable dynamic access in one documented boundary considered for a narrow checker exemption rather than a broad baseline allowance.

Scope

• Marketplace, MCP, and settings package exports
• Platform helpers in hooks/visualizer/utils
• Remote workspace response status normalization
• Laminar root-span compatibility and model display-name helpers

Acceptance Criteria

• Public package exports use explicit typed mappings or direct exports without open-ended module probing.
• Platform and optional-library feature detection is centralized in focused compatibility helpers.
• Remote response and observability compatibility behavior has targeted tests.
• Any unavoidable boundary exception is narrow, documented, and enforced by tests rather than left in the general baseline.
• Relevant forbidden dynamic-attribute baseline entries are removed and public import compatibility passes.

This issue was created by an AI agent (OpenHands) on behalf of the user.

Start by reading parent issues #4903 and #4905, then inspect the Marketplace, MCP, and settings exports plus platform helpers in hooks/visualizer/utils. Trace the remote workspace response, Laminar root-span, and model display-name compatibility paths. Done means focused helpers and explicit exports replace scattered probes, targeted tests pass, and the relevant baseline entries are removed.