[Platform] Define renderer capability tiers and validate every fallback

[proggeramlug]

Parent: #126
Related existing platform issues: #18, #55, #74

Problem

Bloom targets Metal, DX12, Vulkan, WebGPU, Android, Apple mobile/spatial/watch platforms, but renderer feature behavior is not defined as one capability contract. Desktop defaults can exceed adapter limits (#55), some platforms contain stubs/no-ops, and CI does not execute every target. High-end work will worsen this unless fallbacks are explicit and testable.

Outcome

Data-driven renderer capability tiers selected from actual adapter features/limits, queryable by games, forceable in tests, and covered by a platform/fallback matrix.

Tier contract

Define names based on capabilities rather than marketing; an initial shape may be:

• Baseline: conventional material bindings, CPU draws, reduced MRT/post-FX, conventional shadows, software/screen-space GI fallback.
• Modern: storage-buffer scene data, indirect draws, texture-array/paged indirection, full temporal/post-FX path.
• High-end: descriptor-indexed resources, visibility shading, virtual geometry/shadows, ray-query enhancements.

The implementation may choose different names/count, but each tier must list required features and limits plus per-feature fallback. Never infer high-end solely because the machine is “desktop.”

Capability report

At initialization, produce a structured report containing:

• adapter identity, backend, driver where available;
• all requested vs available features and relevant limits;
• selected tier and reason;
• per-system path: geometry, materials, shadows, GI, reflections, AA/upscale, texture format, path tracing;
• disabled/limited features and their fallback;
• shader compiler state on Windows (DXC/FXC and ray-query consequences).

Expose this read-only report through a Perry-safe TypeScript API and concise startup log. A requested unsupported feature returns a result/error; it may not silently no-op.

Device creation

• Base required limits on adapter.limits() and chosen tier requirements.
• Request only features actually used by the selected tier.
• If preferred-tier device creation fails, retry a documented lower tier and record the cause.
• Add BLOOM_FORCE_RENDER_TIER (or equivalent) for testing lower paths on capable hardware.

CI/qualification matrix

• Compile every supported target that can be compiled in hosted CI.
• Run headless/golden smoke at forced tiers on available desktop backends.
• Run web in a browser with a real canvas/WebGPU adapter, not only cargo check.
• Add scheduled/device-farm or documented release qualification for Android/iOS/tvOS/visionOS/watchOS where hosted runtime execution is unavailable.
• Treat deliberate platform stubs as an explicit capability response and document scope.

Acceptance criteria

• A single table in docs is generated or validated from the same tier definitions used by code.
• Forced lower tiers pass the relevant quality corpus on a high-end adapter.
• An adapter below a preferred limit starts on a lower tier instead of failing device creation.
• TypeScript can query every material rendering feature needed to choose content/settings without parsing logs.
• No public renderer setter silently succeeds when the active platform cannot implement it.
• Platform workflow covers macOS/Metal, Windows/DX12, Linux/Vulkan, web/WebGPU, and compile/release checks for declared mobile/Apple targets.
• Capability snapshots are uploaded with quality/performance results.

Likely files

• device creation under native/*/src/lib.rs
• new shared capability model under native/shared/src/renderer/
• src/core/ public types/API
• tools/validate-ffi.js
• .github/workflows/test.yml, platform docs

Non-goals

• Identical images/performance on every tier.
• Requiring high-end features for engine startup.
• Keeping a platform target “supported” through silent no-op parity.

Dependencies

Should land early; render-foundation issues consume this contract.