bios: add SCPH5552 (EU v3.0 01/06/97) BIOS build profile

[Alexbeav]

Summary

Adds the BIOS profile toml for the European SCPH-5552 v3.0 ROM alongside SCPH1001/SCPH101/OpenBIOS. Profile only; no ROM data and no private seeds.

Commits

• 2b1ed3a bios: add SCPH5552 (EU v3.0 01/06/97) BIOS build profile

Scope

1 file changed, 86 insertions(+)

Validation

Cherry-picked from the Alexbeav/psxrecomp main line, where the same changes pass the recompiler/runtime/runtime-ui ctest gates with only the pre-existing failures (aot_overlay_discovery, release_zip, gte_register_access_test link). This branch was also built on mstan/master as of 01c647e with the same result.

[Alexbeav]

Converting this to a draft after CobaltCryptid's point on Discord, which is correct: this PR only adds the profile toml and does not touch the default PSXRECOMP_BIOS_STEMS, but the runtime currently treats BIOS identity as a two-way choice — savestates are filed under openbios/ when the checksum matches OpenBIOS and under scph1001/ otherwise, and the lobby handshake only carries can_scph1001 / prefer_openbios. A title built against a third BIOS would misfile its savestates and be invisible to the netplay fallback.

Supporting an additional BIOS properly means at least:

1. savestate folder / compatibility keyed by a BIOS token or checksum rather than the OpenBIOS-or-SCPH1001 test;
2. a generalized lobby handshake (advertise the BIOS set each peer can run, fall back to OpenBIOS when the sets do not intersect);
3. detection of which BIOS(es) an executable was compiled with, so the runtime can pick the matching state folder and handshake answer.

Two ways forward — happy to do either:

• park this PR until those layers are generalized (I keep the profile in my fork for local PAL builds only), or
• extend this PR to the three items above, if you would rather see it done in one piece.

Leaving it as a draft until you say which.

[TechnicallyComputers]

I would not merge this yet, if we are going to add support for yet another BIOS bin, we need to implement new handshake behavior in netplay lobbies, new behavior in recomp-ui, new behavior in the launcher... Decide if/how to handle or support multiple retail BIOS in one executable for hotswapping and fallback...

Gamestates and RAM do not match between BIOS versions, which breaks savestates, requiring isolation of savestates in separate folders per-bios, and it also breaks netplay determinism for the same reason, which we currently handle by forcing a handshake between all peers about what BIOS are compiled into their executable, with support for hotswapping between SCPH1001.bin, and openbios - using OpenBIOS as a safe fallback everyone has access to if some peers do not match the retail bios selected by the host.

All of that has to be refactored at retcomm-launcher, recomp-ui, and psxrecomp in order to satisfy the request to add support for a new BIOS. I suggest leaving this open until we can circle back to it.