Model CPU profiles separately from base architectures in the case manifest

## Problem

PR #457 reserves `rhea`, `shakti`, `xiangshan`, and `t-head` in the case manifest's `arch` column. Those names identify processors or implementation profiles, while their base ISAs are AArch64 or RISC-V. Treating both concepts as one dimension will duplicate suites and make target selection ambiguous as Wave moves toward Whale (#93).

## Scope

- Introduce a backend-neutral base architecture plus optional CPU/profile dimension in `tests/cases/cases.toml`.
- Keep OS, support, and CI switches readable at the top of the manifest.
- Derive `shared`, base-architecture, profile, and OS-specific suites without hand-written case lists.
- Migrate the roadmap entries added by #457 without advertising unsupported targets.
- Document how profile extensions and baseline fallback interact.

## Completion criteria

- Rhea resolves to AArch64 and SHAKTI/XiangShan/T-Head resolve to RISC-V without pretending to be new base ISAs.
- The manifest rejects contradictory or unknown base/profile combinations.
- LLVM and future Whale runners can consume the same resolved target identity.
- Existing enabled matrices remain unchanged.

Start with tests/cases/cases.toml and review the roadmap entries introduced by PR #457. Trace how shared, base-architecture, profile, OS, support, and CI switches are currently represented, then define the resolved target identity and validation rules. Done means the listed profiles map to AArch64 or RISC-V, contradictory combinations are rejected, and existing enabled matrices remain unchanged.

Written by the indexing model from the issue text.