[rram] ISFB page test

Nobody has claimed this yet.

On flash, the ISFB security model relies on a hardware-enforced asymmetry: prog_en lets you clear bits (0↔1 → 0, i.e. "strike" a product/add a revocation), but you can only set bits back to 1 via a separate erase operation gated by its own erase_en permission. So an owner can grant a firmware image "can strike, cannot un-strike" by giving it write=true, erase=false — a one-way ratchet. That's presumably the whole point of the isfb_erase manifest extension: only specially-authorized images get to reset the page.

On RRAM, there's no such split. dif_rram_ctrl_region_properties_t only has rd_en/wr_en/scramble_en/ecc_en — no erase_en at all. A single RRAM write can set any bit to any value, both directions, in one shot. And nvm_testutils_info_page_setup()'s own comment confirms perms.erase is silently ignored on RRAM. So an owner config that says "this image can write but not erase" no longer actually restricts anything on RRAM — any image with plain write access to the ISFB page could flip a struck bit back to 1 directly, without ever needing whatever permission isfb_erase was supposed to gate.

see https://github.com/lowRISC/opentitan/pull/30424

We either have to move this strike possibility to an OTP partition (also on RRAM) or implement it in a different way

@moidx @andreaskurth @luismarques

Start by reviewing pull request 30424 and the ISFB page test context. Compare the flash permission model with dif_rram_ctrl_region_properties_t and nvm_testutils_info_page_setup(), especially the handling of perms.erase on RRAM. Done means an agreed design preserves the intended write-without-erase restriction for RRAM and is covered by the relevant ISFB tests.

Written by the indexing model from the issue text.