Isolate concurrent live browser suites or enforce sequential execution

[jeremi]

Observation

During Registry Stack v0.15.2 validation, just portal-live-e2e and just home-live-e2e were started concurrently against the same fresh Compose topology.

The home suite completed with 44 passing tests and 6 environment-specific skips. One portal test failed:

child benefit delegated two-hop: the civil read resolves only after consent + guardian link

The page showed a verified guardian link followed by:

Couldn't reach Civil Registration Authority just now. Other evidence is unaffected.

The same complete portal suite was rerun alone immediately afterward and passed 8/8. The delegated two-hop resolved in under one second. The full live smoke had also passed before the browser run.

This currently looks like shared test-environment contention rather than a Registry Stack v0.15.2 product regression. The release-candidate workflow runs the suites sequentially, but the local targets do not document or enforce that constraint.

Outcome

Either make the two live browser suites safe to execute concurrently or make sequential execution an explicit, enforced contract so transient shared-state failures are not mistaken for product regressions.

Acceptance criteria

• Attempt to reproduce the failure with repeated concurrent portal/home runs against one fresh topology.
• Identify the contended resource or shared mutable scenario state if reproducible.
• If concurrency is supported, isolate per-suite sessions/state and add a bounded concurrency regression test.
• If concurrency is intentionally unsupported, add one aggregate sequential target and document that the individual live suites must not run concurrently against the same Compose project.
• Preserve the delegated two-hop assertion. Do not hide authority failures with retries that convert an actual failed evaluation into success.
• Keep release-candidate execution deterministic and retain the existing sequential ordering.