[TianDi101]

…g::medium

PoolClient::Init registered DRAM unconditionally and then added HBM/SSD beside it, so --tier hbm or --tier ssd produced a two-backend node. That reads like a tier stack and is not one: since Phase 4 the master treats every advertised tier as an equally valid put target, so the second medium is mirrored into by free capacity rather than sitting behind the first. A node's keys split across two pools for no gain, and a tier benchmark ends up measuring DRAM.

Replace the per-medium enabled flags with a single selector. A node picks exactly one of DRAM / HBM / SSD; heterogeneity comes from different nodes picking differently, which the routing plane already handles. Adding a medium is now a case in one switch, not another if.

• UMBPDistributedConfig::medium (new UMBPMedium enum) replaces enable_ssd_tier and UMBPHbmConfig::enabled. Defaults to DRAM, so an existing deployment is bit-identical.
• UMBPConfig::Validate checks only the selected medium's sizing; the unselected blocks are ignored, not validated, so one deployment template can carry all three.
• PoolClient caches the live tier as medium_ and exposes Medium().

Also removes the two DRAM literals the design doc listed as outstanding:

• the re-cache installer hardcoded TierType::DRAM, which would have installed into a tier an HBM/SSD node does not have;
• PartitionBatchPutTargets filtered remote routes to DRAM/HBM, silently dropping every put master routed to a peer's SSD even though SSD publishes ordinary registered staging pages. New test CrossNodeBatchPutLandsOnSsdPeer covers exactly this.

Tests: 20/20 umbp ctest targets pass (incl. the new test_umbp_medium_selection: lowering, per-medium validation, one-backend registry, and the cross-node SSD put/get).

Motivation

Technical Details

Test Plan

Test Result

Submission Checklist

• Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.