Split candidate names into first and last name fields

REQUEST

I want candidates to have separate First name and Last name fields instead of one Full name field. Please update the Add Candidate and Edit Candidate forms to use First name and Last name. Candidate lists and candidate profiles should continue displaying the person’s complete name. Migrate all existing candidates automatically. For existing names, use the first word as the first name and everything after it as the last name. If a candidate only has one word in their name, keep it as the first name and leave the last name empty. Candidate search must work with either the first name, last name, or complete name. Make sure existing candidate notes, assigned jobs, pipeline stages, email addresses, and other information are preserved. Please test that Ava Chen is migrated to: First name: Ava Last name: Chen Also verify that her existing notes, assigned job, and pipeline stage still work after the migration. Do not modify the production application or production database. Build this as an isolated preview.

APPROVED PLAN

1. User-visible behavior

- Add/Edit Candidate forms use required First name and optional Last name fields.
- Candidate lists, profiles, initials, and search display/use the complete name.
- Search matches first name, last name, complete name, and existing candidate metadata.
- Existing candidates are migrated automatically using:
  - First word → first name
  - Remaining words → last name
  - Single word → first name only
- Ava Chen becomes First name `Ava`, Last name `Chen`; her note, assigned job, and `interview` stage remain intact.

2. Frontend changes

- Update `Candidate`/`CandidateInput` types and fallback demo data.
- Replace the form’s `Name` field with `First name` and `Last name`.
- Add a shared complete-name formatter for lists, profiles, initials, and display.
- Update client-side search to include first name, last name, complete name, title, company, and location.
- Update Playwright selectors and workflow assertions.

3. Backend and Convex changes

- Change API validation and Convex create/update mutations to accept `firstName` and `lastName`.
- Store normalized trimmed names and preserve email, title, company, location, stage, and job assignment.
- Replace `candidates.name` with `firstName` and optional `lastName` in the final schema.
- Rebuild `searchText` from complete name plus existing searchable metadata.
- Update dashboard serialization and fallback data.
- Keep notes and job references keyed by stable external IDs.

4. Versioned migration

Yes. This is a breaking stored-data change.

- Bump the application/migration version from `0.1.0` to `0.2.0`, with exact `from: "0.1.0"`.
- Add `.factory/schema.transition.ts` with a widened candidate shape accepting old `name` records and new first/last-name fields.
- Extend the existing full application-table snapshot mechanism (`users`, `jobs`, `candidates`, `notes`) using `migrationBackupRows`.
- Forward migration:
  - Parse each old `name` with the requested first-word rule.
  - Write `firstName`/`lastName`.
  - Remove the legacy `name` field.
  - Recompute `searchText`.
  - Remain idempotent on reapply.
- Rollback restores the snapshot, including legacy names; regenerated Convex IDs and declared `jobId`/`candidateId` references are rewritten through the existing ID-map mechanism.
- Validation must check row counts and invariants: candidate/job/note counts, stable external IDs, note ownership, job assignments, stages, email addresses, and complete transformed names.
- The orchestrated preview lifecycle remains apply → validate → rollback → validate old data → reapply → validate final data, followed by deployment of the narrow final schema.

5. Tests and browser verification

- Add migration unit coverage for multi-word and single-word names, idempotence, rollback, counts, and preserved relationships.
- Update data tests for first/last-name create/update behavior and search.
- Add explicit Ava assertions for:
  - `Ava` / `Chen`
  - existing Juniper Works job assignment
  - `interview` stage
  - existing note body and candidate association
- Update the browser smoke test to create/edit candidates with separate fields and verify complete-name display and searches by first, last, and full name.
- Run the configured typecheck, unit tests, build, isolated Convex migration lifecycle, and Playwright smoke test.

6. Risks or questions

No safety blocker was found for an isolated preview. Production remains untouched if the factory uses its existing cloned-preview workflow and factory-only migration guards.

Primary implementation risk is ensuring the transient schema is active during both rollback and reapply; the factory’s `prepare-migration` flow is designed for this and should be used.