[dv,sram,earlgrey] Extend DV infrastructure to secondary SRAM ctrl

#30611 introduces a secondary SRAM controller (`sram_ctrl_sec`) that extends the main SRAM of Earlgrey from 128 KiB to 192 KiB of contiguous space. The chip-level DV that verifies the main SRAM controller must be extended to cover the secondary instance. #30611 updates the `chip_sram_ctrl` testplan text to claim coverage of the secondary SRAM, but the supporting DV infrastructure and tests are not yet in place, so the testplan currently overstates actual coverage.

### Tests to extend

- [ ] **Memory wipe (MEMSET)** — `//sw/device/tests:sram_ctrl_memset_test` (`sw/device/tests/sram_ctrl_memset_test.c`). Currently exercises only the retention SRAM (`kDtSramCtrlRet`) — not even main, since the program runs out of main SRAM and cannot safely wipe it. The secondary SRAM is *not* used for runtime execution, so it can be wiped and verified exactly like the retention SRAM; add a `kDtSramCtrlSec` pass (write data → INIT wipe → confirm cleared). Uses the DT-based DIF, so it only needs the generated `kDtSramCtrlSec` handle — no backdoor infrastructure below is required for this one.
- [ ] **Scrambled access** — `chip_sw_sram_ctrl_scrambled_access_vseq.sv` / `sw/device/tests/sram_ctrl_scrambled_access_test.c`. #30611 only re-indexed the retention-SRAM key slots (`RET_INDEX`/`RET_REQ_INDEX`) after the OTP key-request shift; the sequence still exercises only main + retention. Add a secondary-SRAM scramble/check phase (needs the backdoor handle below).
- [ ] **Instruction fetch / execution** — `chip_sw_sram_ctrl_execution_main_vseq.sv` / `sw/device/tests/sim_dv/sram_ctrl_execution_main_test.c`. Hardcoded to `TOP_EARLGREY_SRAM_CTRL_MAIN_RAM_BASE_ADDR`. The secondary has `InstrExec=1`, so the full IFETCH-enable matrix (OTP `HW_CFG1[IFETCH]` × `HW_DEBUG_EN` × `EXEC CSR`) should be verified for it as well.

### DV infrastructure gaps (needed by the scrambled-access and execution tests)

- [ ] **Backdoor memory handle.** `chip_mem_e` in `hw/top_earlgrey/dv/env/chip_env_pkg.sv` only defines `RamMain[16]` and `RamRet[16]`; there is no `RamSec` entry, so `mem_bkdr_util_h` has no backdoor handle for the secondary SRAM. Add the tiles and the corresponding `mem_bkdr_util` instantiation/scrambling-key wiring.
- [ ] **Invalid-tile guard.** `hw/top_earlgrey/dv/env/chip_env.sv:39` hardcodes the `[RamMain0:RamMain15]` range for the unused-tile check; extend it for the secondary tiles.
- [ ] Note: the `bkdr_loader` path already has a `BkdrSramSec` target (added in #30611); this is separate from the UVM `mem_bkdr_util` path above, which is what the SRAM tests rely on.

### Already covered by #30611 (no action needed)

- Escalation reset: `chip_sw_all_escalation_resets_vseq.sv` already maps the `sram_ctrl_sec` `prim_reg_we_check` alert to `TopEarlgreyAlertIdSramCtrlSecFatalError`.

### Acceptance

Every "secondary SRAM" claim in `hw/top_earlgrey/data/ip/chip_sram_ctrl_testplan.hjson` is backed by an implemented, passing test, and the secondary SRAM is reachable via the DV backdoor (`mem_bkdr_util`).

Start with the listed SRAM tests and sequences, then inspect chip_env_pkg.sv and chip_env.sv for the existing RamMain/RamRet backdoor setup and invalid-tile check. Extend the MEMSET, scrambled-access, and execution coverage described in the issue, including the secondary backdoor path. Done means the tests pass, the secondary SRAM is reachable through mem_bkdr_util, and each testplan claim is backed by coverage.

Written by the indexing model from the issue text.