Hotfix: regenerate uv.lock to include python-multipart

The Dockerfile uses ``uv sync --frozen`` which installs strictly from
uv.lock, not pyproject.toml. The python-multipart dep was added to
pyproject.toml in the Wave 2 work (PR #3, commit e290d9e) to fix
FastAPI's multipart/form-data parsing on /workspace/transcribe and
/workspace/feedback — but the lockfile was never regenerated, so
the production Docker image kept building without it.

Result: after PR #3 merged to main, the new container crash-looped
on import:

    File "/app/backend/routers/workspace.py", line 189, in <module>
        @router.post("/transcribe")
    ...
    RuntimeError: Form data requires "python-multipart" to be
    installed.

The GH Actions "Deploy to VPS" job was stuck on the health-check
step because the container couldn't start. Same root cause is why
the earlier ``Add .coderabbit.yaml`` deploy at 07:44Z this morning
failed too (the lockfile gap predated that commit but no deploys
had been triggered since the cosmetic Wave 2 PRs landed).

Fix: ``uv lock`` to regenerate uv.lock against the current
pyproject.toml. python-multipart v0.0.20 now appears in the
lockfile and the next Docker build will install it.

No code changes; lockfile-only. CI tests already covered the
multipart-import path (test_transcribe + test_feedback) so green
tests don't guarantee a green deploy when the lockfile drifts —
something to flag in the Dockerfile docs as a follow-up.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: LEANDERANTONY