live_status is now stored as a display-ready string (e.g.
"Remote command started") rather than a code (e.g. "started").
The frontend renders it directly instead of mapping codes to messages.

Updated: remote_trap.py, lab_facade.py, remote_job_status_service.py,
JobProgress.tsx, and corresponding tests.

Set live_status at each phase of LocalProvider.launch_cluster():
- "Preparing environment" before venv creation
- "Running setup" before setup commands run
- "Starting service" before the run command launches

This fills the visibility gap between job creation and
tfl-remote-trap taking over with "Remote command started".

Makes live_status updates visible more quickly in the UI.

The previous approach called job_service via asyncio.run() from the
executor thread, which failed because the org context var wasn't
propagated. Switch to a callback pattern: the queue worker (which
has the right async context) passes an on_status callback to
launch_cluster(), using run_coroutine_threadsafe to bridge the
thread boundary.

run_coroutine_threadsafe doesn't propagate contextvars from the
calling task. Set the organization_id explicitly in the coroutine
so the job directory can be resolved correctly.

This reverts commit 2803287.

This reverts commit c2977bb.

- Add note about reinstalling lab-sdk after changes (cd lab-sdk && pip install -e .)
- Point agents to relevant docs based on whether they're working on frontend or backend
- Document context var pitfall: org_id doesn't propagate to new threads/coroutines and must be set explicitly