feat(jobs): complete workspace draft parity

docs/architecture/application-workspace.md

@@ -6,7 +6,7 @@
 
 ## What it is
 
-A dedicated surface for one `JobApplication` at `/applications/{id}`, so an application is a place you
+A dedicated surface for one `JobApplication` at `/jobs/{id}`, so an application is a place you
 work rather than a row you edit in a modal. Job tracking stays the product; the workspace is the
 application's home.
 
@@ -23,6 +23,7 @@ The workspace **owns no data and duplicates none**. It is an aggregate read plus
 | Checklist | `ApplicationChecklistItem` — completion state only, seeded from the readiness signals |
 | CV | Phase 4 `CvVariant` — a lens over the master `CareerProfile`; the application only points at one |
 | Cover Letter | `JobApplication.CoverLetterText` + `CoverLetterVersions` history |
+| Application answers / recruiter draft | compatibility fields on `JobApplication`, exposed as separate workspace fields |
 | Analysis / Match / Interview | Phase 5 `AiWorkspacePanel` + `AiInteraction` history |
 | Documents | `Attachment` |
 | Communication | `Correspondence` |
@@ -134,13 +135,14 @@ rejecting a duplicate system key, and NULL system keys not colliding.
 
 ## Frontend
 
-`ApplicationWorkspacePage` (`/applications/:id`) — a left nav plus a content pane, section selected by
-`?section=`, so a section is linkable and survives refresh. Reached from the job dialog's "Open
-application workspace" button.
+`ApplicationWorkspacePage` (`/jobs/:id`) — a left nav plus a content pane, section selected by
+`?section=`, so a section is linkable and survives refresh. The whole application row/card opens this
+route; the legacy job-details dialog is not part of the production navigation flow.
 
-The dialog passes an optional `onOpenWorkspace` callback rather than calling `useNavigate` itself:
-`JobDetailsDialog` must stay renderable without a `<Router>` (several suites mount it standalone), so
-router context belongs to the caller.
+Cover-letter and application-package editors report dirty state to the workspace. Section changes,
+Back/Forward navigation and application exit use the shared application confirmation dialog, while a
+hard refresh receives the browser's unload warning. Returning through the workspace Back action
+restores focus to the originating application row.
 
 The Checklist section (`ApplicationChecklist`) groups items by category, shows a completion bar, and
 supports tick/untick, add, remove and reorder. System items are labelled "Detected" when a signal
@@ -289,6 +291,15 @@ the builder. Nothing auto-applies, and no suggestion mutates a variant or the pr
 Creation methods: write it, start from the built-in template, or generate from the AI panel below the
 editor. The editor is always the user's; generation is never triggered by opening the page.
 
+### Application answers and recruiter message
+
+The Cover Letter section also owns the saved application answer and recruiter-message editors that
+were previously reachable only through the retired modal. The existing database representation is
+kept for compatibility: the application answer remains a marked block in `JobApplication.Notes`, but
+the workspace aggregate separates it from human notes and the API owns insertion/removal. General job
+edits preserve the answer, and the ordinary Notes UI never exposes the storage markers. Empty saves
+can intentionally clear either draft.
+
 ### Documents
 
 Unchanged. The existing `Attachments` component and `/api/attachments` already handle CV, cover