[Arcilator] Define the long-term strategy for FIRRTL probes and sv.xmr.ref

Nobody has claimed this yet.

Arcilator currently receives `sv.xmr.ref` and `hw.hierpath` from FIRRTLToHW for FIRRTL probe semantics. The existing `arc-resolve-xmr` pass handles a restricted read-only subset by boring referenced signals through module ports and replacing XMR reads with ordinary SSA values.

However, it is unclear whether this is intended to be the long-term architecture or only a compatibility path.

A major limitation is bind-context XMR. FIRRTL-generated `sv.bind` operations are commonly guarded by `sv.ifdef`, while `arc-resolve-xmr` currently only supports unconditional binds. Resolving these cases generally requires first evaluating the SV conditional configuration to determine which bind instances exist.

This means that fully supporting the current FIRRTLToHW output may require Arcilator to implement a configuration-aware SV preprocessing or elaboration stage before resolving XMRs. This seems undesirable for a non-SV backend, especially since the original probe, layer, and conditional-presence semantics were available before lowering to SV constructs.

Possible directions appear to be:

1. Keep `arc-resolve-xmr` as the supported boundary and extend Arcilator with SV conditional-processing semantics.
2. Eliminate probes earlier using `ProbesToSignals`, provided it can become load-bearing for modern Chisel designs.
3. Preserve probes through a non-SV Core-level representation and lower them separately to SV XMRs or explicit HW ports.

The ongoing Probe dialect RFC and #10818 explore the third direction, but this issue is not intended to assume that the proposed dialect must be accepted. The goal is to clarify the downstream requirement even if that proposal is rejected.

It would be helpful to agree on:

* Is `sv.xmr.ref` an acceptable long-term input contract for Arcilator?
* Is Arcilator expected to evaluate `sv.ifdef` and conditional bind topology?
* Should probes instead be eliminated or represented before FIRRTLToHW emits SV operations?
* Which route should contributors prioritize?

Related:

* #10096 — `arc-resolve-xmr`
* #10818 — Core-level read-only Probe dialect
* [RFC: A Core-Level Probe Dialect](https://discourse.llvm.org/t/rfc-a-core-level-probe-dialect/91315)

CC @fabianschuiki @fzi-hielscher @seldridge

Start by reading #10096 on arc-resolve-xmr, then compare the Probe dialect RFC and #10818 with the FIRRTLToHW output described here. Map the implications of each proposed direction, including conditional binds and sv.ifdef; done means agreement on Arcilator's long-term input contract and the route contributors should prioritize.

Written by the indexing model from the issue text.