build(demo): commit demo/Gemfile.lock so the demo image is reproducible

[ivndev001]

What to build

demo/ is an application, not a library, but its lockfile is ignored (demo/.gitignore:6 Gemfile.lock). The demo image runs bundle install against demo/Gemfile at build time (Dockerfile:45-46) with gem "rails", "~> 8.0" and unpinned sqlite3 / puma (demo/Gemfile:5-7), so two builds of the same commit can ship different Rails, puma and sqlite3 versions, and a release's demo (release.yml:208-213 deploys it after every gem publish) can change behaviour with no diff in the repo. The root Gemfile.lock is deliberately ignored because the root is a gem (bench.yml:32-34 explains); that reasoning does not apply to demo/.

Commit demo/Gemfile.lock: remove the line from demo/.gitignore, generate the lock with the Ruby the Dockerfile uses (ruby:3.4-slim-bookworm, Dockerfile:24 — run cd demo && bundle lock --add-platform x86_64-linux --add-platform aarch64-linux so the Docker build resolves without re-locking), and switch Dockerfile:46 to bundle install --jobs 4 --retry 3 --frozen so a stale lock fails the build loudly instead of silently re-resolving. gem "wurk", path: ".." (demo/Gemfile:11) locks as a path gem with the current Wurk::VERSION; document in demo/README.md that a version bump must be followed by cd demo && bundle lock (add it to RELEASE.md step 1 as well, one line). Dependabot's bundler entry is scoped to / (.github/dependabot.yml:9-10) and its comment calls demo a fixture — leave that alone; the lock is for reproducibility, not for automated bumps.

Acceptance criteria

• demo/Gemfile.lock is tracked and lists platforms x86_64-linux and aarch64-linux.
• docker build -t wurk-demo-test . succeeds from the repo root on the committed lock.
• bundle exec rake release:check still passes (the lock does not touch the root tree's clean-tree check at Rakefile:22-27 once committed).
• RELEASE.md step 1 and demo/README.md mention re-locking after a version bump.
• gates green: rubocop, rake test, rake test:parity (bin/check exit 0)

Affected paths

demo/.gitignore, demo/Gemfile.lock (new), Dockerfile, demo/README.md, RELEASE.md

Verified against

c346bc9

[ivndev001]

Blocked from the agent side, and the blocker is not in this repo.

This asks for demo/Gemfile.lock to be committed. Producing a lockfile requires bundle lock / bundle install against the demo Gemfile — there is no way to author a correct one by editing text.

No machine available to the agent fleet has Ruby or Bundler:

command -v ruby bundle   # -> nothing, on this box and on all 27 runner boxes

That is tracked as developerz-ai/developerz.ai#2950 (no runner box has a Ruby toolchain; wurk coding tasks cannot run bin/check) and needs box-level access the fleet does not have.

Every other afk issue in this batch was shippable because it is verifiable by reading — docs, workflow YAML, dependabot config, dead rubocop directives. This one is not: a hand-written lockfile that resolves differently from the real one is worse than none, and CI would be the first place anyone found out.

Labelling hitl. Unblocks the moment any box in the loop has Bundler, or a human runs bundle lock in demo/ once and commits the result.