fix(bioreactor-v1): drop require_live_session, rejected by bread 0.3.0

[CameronBrooks11]

Unblocks the #138 real-Pi acceptance run. Found on hardware.

The bug

bread 0.3.0 removed hardware.require_live_session and rejects it at load time as an unknown key — its CHANGELOG says so explicitly:

Removed hardware.require_live_session config field. […] Configs with require_live_session will be rejected at load time as an unknown key.

The machine-profile pin moved bread 0.2.11 → 0.3.0, but the provider configs still set the field. So on the Pi, bread exited instantly, the runtime's hello handshake failed on the dead stdout pipe, and the runtime aborted:

[bread0] Spawning: /opt/anolis/bin/anolis-provider-bread
[bread0] Process spawned successfully (PID=24441)
[ERROR] Unknown hardware key: 'require_live_session'
[bread0] Hello handshake failed: poll error on stdout pipe
Runtime initialization failed: Failed to start provider 'bread0'

A breaking change shipped under a minor bump, with nothing validating the project configs against the pinned provider.

The fix

Remove the key. Its intent is now carried by bus_path: a real path opens a live CRUMBS session and startup throws if the bus cannot be opened (a mock:// path seeds an inventory instead). Both projects already use /dev/i2c-1, so behaviour is preserved exactly.

Also bumps the runtime pin to 0.1.32 — the release carrying the install.sh non-loopback-auth fix (anolishq/anolis#172).

Verification

Against the released bread 0.3.0 binary's --check-config, not just source reading:

• Old config reproduces the exact bench failure: Unknown hardware key: 'require_live_session', exit 1.
• All 4 bread configs in this repo now validate.
• All 4 ezo configs validate against ezo 0.3.0 (no second landmine).

Follow-up

anolis-workbench still renders this key (core/renderer.py:225), declares it in catalog/providers.json, seeds it into both project templates, and types it in frontend/src/lib/contracts.ts. Any bread project workbench generates is dead on arrival against bread 0.3.0. Fixing separately.

Worth considering a CI gate that runs each provider's --check-config against the project configs at the pinned version — this class of breakage is entirely mechanical to catch.