deps: refresh the dev lockfile within its constraints; cap parallel and simplecov for the 3.2 floor

[minerva-sky]

Closes #64.

bundle update on main, honouring every cap already in the Gemfile, moves 51 gems. The runtime ones are the versions every fresh gem install agentic already resolves to while CI tested the old numbers: json 2.7 → 3.1, zeitwerk 2.6 → 2.8, dry-schema 1.13 → 1.16 (dry-core 1.0 → 1.2, dry-types 1.7 → 1.9, dry-logic 1.5 → 1.6), async 2.24 → 2.37 (the Gemfile's own cap, which the lock never reached), thor 1.3 → 1.5, net-http 0.4 → 0.10, faraday 2.14 → 2.15. Dev side: standard 1.32 → 1.57 (rubocop 1.91, so Ruby 3.4 syntax lints), rspec 3.13.2, webmock 3.34, simplecov 1.2, rake 13.4.

What changes

• Gemfile.lock: the refresh. Not shipped in the gem, so consumer resolution is byte-for-byte unchanged; this only changes what CI exercises.
• Gemfile: two more caps in the existing Ruby 3.2.4 floor block, parallel < 2 and simplecov < 1.3, because the panel caught that both had crossed to a 3.3 floor in the refresh (resolved locally on 4.0.2, where the floor is invisible). Every locked spec now satisfies required_ruby_version on 3.2.4. These caps go with the four existing ones when deps: raise Ruby floor to >= 3.2 and test a real CI matrix (#15) #27 / CI tests async 2.24 while consumers on maintained Rubies resolve 2.46: the 3.2 caps in Gemfile freeze every matrix leg #42 land.
• authentication_system.rb: the dead require "base64" is deleted. The refresh drops the orphan base64 (0.2.0) entry that vcr 6.3 pulled in, which was the only thing letting that line load on Ruby >= 3.4, and the file never calls Base64. Identical hunk to fix: ArtifactGraph on stdlib TSort; declare every runtime dependency lib/ requires #74, so either merge order is clean (the lock will need a re-resolve after whichever merges second; both are mechanical).

Tests (Ruby 4.0.2, refreshed lock): 1391 examples, only the pre-existing event_dispatcher_integration_spec.rb:291 wall-clock flake (#36); earlier run also hit the plan_orchestrator_spec.rb:243 UUID-redaction flake (#54). standardrb 1.57: no offences. CI's 3.2.4 leg is the gate that matters here; the floor check is the local proxy for it.

Worth a follow-up, not in this PR: json 3.x raises on duplicate keys and comments where 2.x took last-wins. Consumers already get 3.x (the gemspec never pinned json), and every LLM-facing JSON.parse in lib/ is rescued, but nobody has decided whether allow_duplicate_key: true is the intended policy for model output. Two seats raised it independently.

Intended labels: loop:drain, loop:deps.

Panel

• DHH: cleared (3/3). Lockfile roll plus a dead require deleted; nothing to mimic or abstract. All three flagged the pre-existing tension between the Gemfile's 3.2.4 caps and WORLD.md's "track the latest stable Ruby" as the real smell, owned by deps: raise Ruby floor to >= 3.2 and test a real CI matrix (#15) #27 / CI tests async 2.24 while consumers on maintained Rubies resolve 2.46: the 3.2 caps in Gemfile freeze every matrix leg #42.
• Obie Fernandez: objected-then-cleared. Round 1 (3 seats): 2/3 objected on unhandled failure modes: parallel 2.3.0 and simplecov 1.3.2 need Ruby 3.3, so CI's frozen install on 3.2.4 dies before rake. Fixed in 787feda (caps + re-lock, floor check clean). Round 2: cleared 3/3, having re-run the floor check and probed async 2.37's Barrier/Queue/Semaphore against the orchestrator and json 3.1's stricter parse against every JSON.parse in lib/.
• Vladimir Dementyev: objected-then-cleared. Round 1: 3/3 objected on the same floor break (deterministically red, not flakier). Round 2: cleared 3/3 after re-running the floor check; PLATFORMS (ruby + arm64-darwin-23) and BUNDLED WITH unchanged, prism 1.9 is the only new native build and is cache-keyed, lint ruleset pinned by .standard.yml so local and CI agree.
• The gem consumer: cleared (3/3). Gemfile caps and lock are dev-only; gemspec untouched; Base64 referenced nowhere in lib/spec/exe; nothing serialised changes shape.

🤖 Generated with Claude Code