[docs] Rewrite Job Application Assistant docs for JobApplyWorkflow

[serge-ivo]

Problem

The Job Application Assistant docs describe the old runtime-task flow instead of the current LLM-driven apply workflow.

The README still references FAGS, job.apply_basic, manual run_instance_task / approve_instance_task, and direct /applications endpoints. Current platform code starts the apply flow through POST /v1/instances/:instanceId/apply, which launches JobApplyWorkflow and drives the runner through /browser/snapshot and /browser/act.

Evidence

• Stale doc: platform/agents/job-application-assistant/README.md
• Current route: platform/workers/api/src/routes/instances-apply.ts
• Agent tool path calls startJobApply: platform/workers/api/src/lib/storage-tools.ts
• Root README already describes the newer route: platform/README.md
• Manifest still declares old task types: platform/agents/job-application-assistant/agent.json

Scope

• Replace FAGS terminology with ProAgentStore/PAGS terminology.
• Replace job.apply_basic / task approval docs with the current POST /v1/instances/:id/apply flow.
• Document dryRun, resumePath, profile/resume behavior, human handoffs, takeover/resume routes, and expected runner requirements.
• Decide whether agent.json taskTypes / approvalRequiredFor should be updated or explicitly marked legacy.
• Remove or clearly mark the direct worker /applications API section if it is no longer the current product path.

Acceptance Criteria

• The Job Application Assistant README matches the implemented workflow route.
• No current docs tell users to run job.apply_basic as the normal path.
• Safety docs explain the current dry-run and handoff behavior accurately.

[serge-ivo]

Status update after docs/code audit: keep open. The README and public docs now describe JobApplyWorkflow and /v1/instances/:id/apply, but agents/job-application-assistant/README.md still documents direct Worker /applications endpoints and examples. The ticket's acceptance says to remove or clearly mark that direct Worker API if it is not the current product path.

[serge-ivo]

Shipped in 46dab19's stack — a031b89.

The README now leads with JobApplyWorkflow and POST /v1/instances/:id/apply, written from the workflow source: field semantics, the résumé signed-URL transfer, the single-flight 409, the three handoffs (challenge / stuck / needs_input) and their routes, the three data planes, and the per-ATS tips cache.

Three corrections to the issue's own premises, found by reading the code:

• submit_job_application is not a separate implementation. The name is legacy, but storage-tools.ts calls the same startJobApply(). Documented as the chat entry point into the one apply path — including that it does not pass dryRun, so a chat-initiated apply really submits. That is a live footgun worth knowing about.
• agent.json was already correct on the part the issue doubted: it declares job.apply_agent, not job.apply_basic. approvalRequiredFor: [] is deliberate (the gate is dryRun + MCP scope, not per-task approval) and is now documented as such rather than changed. Its description was the stale field; fixed.
• requirePro on the route is currently a no-op — PAGS billing is deferred and PAYWALL_ENFORCE is commented out in wrangler.toml. Writing "requires Pro" would have sent people hunting a paywall that is not switched on.

The stale /applications Worker section is kept but marked legacy: nothing in .github/workflows deploys it and no console/CLI/MCP caller touches it.

One thing the issue did not mention: the live catalog row still described the agent as using "the approved local browser runner task job.apply_basic". That is the most user-visible copy of the stale claim, so it was updated too.