feat: Tailor workspace + background action workers (closes Phase 1 item #6)

[Harikeshav-R]

What & why

The final slice of Phase 1 item #6 (PROJECT.md §8, screen #4) — the Tailor workspace plus wiring the long-running AI/render/open services through Textual thread workers. With this, item #6 is complete and the Phase 1 core loop closes: onboard → master resume → scrape → score → tailor + cover letter → render → track, all from the CLI or the TUI.

Every Atlas service is synchronous and blocks — the AI provider chain runs a subprocess (Claude Code) or a network call (OpenRouter), and rendering runs WeasyPrint — so running them on Textual's event loop would freeze the UI (§8 requires long-running actions to run async). This PR adds the first worker in the codebase.

What changed

• TailorWorkspaceScreen (atlas.tui.screens.tailor_workspace) — opened from Application detail (t). Shows the master-resume blocks, the latest tailored selections (content_id · included · reason · text), and a materials summary; runs four actions: Tailor (t), Cover letter (c), Re-render (r), Open (o). Read-only panes this PR — interactive editing is the deferred follow-up.
• Thread workers — each action is @work(thread=True, exclusive=True, exit_on_error=False); on_worker_state_changed refreshes + toasts on success and surfaces the service's typed errors (TailoringError/CoverLetterError/RenderError/FileOpenError/…) on failure without tearing down the app.
• AtlasApp boundaries — injected provider/renderer/opener/tailoring/render_config/renders_dir (all optional) + run_tailor/run_cover_letter/run_rerender/run_open (each a short session_scope + the service, mirroring the CLI) + an actions_enabled property.
• atlas tui builds the provider chain + renderer best-effort (_build_tui_actions), catching ConfigError/RenderError/LLMError and launching browse-only with the Tailor actions disabled + an atlas doctor hint — the read/track screens need no AI, so a missing key never blocks the TUI.
• atlas.tui.data.build_tailor_workspace — the pure view-model builder (reuses the resume/tailor/coverletter getters).

Decisions (confirmed up front)

• Scope: view + run actions (Tailor / Cover / Re-render / Open). Interactive editing (include/exclude/pin), per-section regenerate, and the Questions tab stay with the deferred PR-2b tailoring depth.
• AI not configured: launch browse-only (inject boundaries into AtlasApp; disable actions with a hint) rather than failing.

How thread workers are tested at 100% coverage

The key finding that de-risked this: await pilot.app.workers.wait_for_complete() awaits a thread worker deterministically inside run_test(), and exit_on_error=False + on_worker_state_changed makes the error path assertable. Hermeticism comes from injecting the existing FakeLLMProvider / FakePdfRenderer / FakeFileOpener + a tmp_path renders dir at the app boundary, so a worker never makes a real AI/render/subprocess call.

Key commits

• feat(tui): add the tailor-workspace view-model builder
• feat(tui): add the Tailor workspace screen with thread-worker actions
• feat(cli): build the TUI's AI/render boundaries best-effort
• docs: record the Tailor workspace and close Phase 1 item #6

Testing

• ruff format --check + ruff check clean; mypy --strict clean on Linux and --platform win32.
• Full suite 776 passing at 100% line + branch coverage. New Pilot tests drive each worker to completion and assert: the DB result (success), that nothing persisted (worker error handled), and that browse-only disables the actions.
• uv build confirms the wheel is unchanged in shape (app.tcss + the new screen ship).

No migration; no dependency changes (textual/pytest-asyncio landed with the core-TUI PR). Closes #6.