Show Candidate Email in Profile.

REQUEST

Hi. In the candidate detail drawer, display the candidate’s email address beneath their title and company. Make it a clickable mailto: link and add an automated test for it. Do not change the database schema or migrate any data.

APPROVED PLAN

1. User-visible behavior

In the candidate detail drawer, show the candidate’s email beneath the title/company line. The email is rendered as a clickable link with an `href` of `mailto:<candidate email>`.

2. Frontend changes

- Update `components/recruiting-app.tsx` in the drawer header to render the email link.
- Add minimal styling in `app/styles.css` so the email appears on its own line and matches the drawer design.
- No changes are needed to candidate forms or client-side types; `Candidate.email` already exists.

3. Backend and Convex changes

None. Candidate email is already:

- Required in `convex/schema.ts`.
- Accepted and normalized by `convex/candidates.ts`.
- Returned by `convex/dashboard.ts`.
- Supported by the API routes and fallback demo store.

4. Migration assessment

No stored-data change is required, so no version bump or migration entry is needed.

The transient widened schema, backup/stash, forward transform, rollback, reapply, and row-count/invariant migration validation are therefore not applicable. Existing records already contain email values and remain untouched. The isolated preview can still verify that candidate records expose non-empty email values, but the migration lifecycle should not be invoked for this UI-only change.

5. Tests and browser verification

- Extend `e2e/factory-preview.spec.ts` to open a known candidate drawer and assert:
  - The email is visible beneath the title/company.
  - A link with the email as its accessible name exists.
  - Its `href` is the expected `mailto:` URL.
- Run the required repository checks:
  - `bun install --frozen-lockfile`
  - `bun run typecheck`
  - `bun run test:run`
  - `bun run build`
  - `bun run test:e2e`
- Browser verification should inspect the link target rather than attempt to launch a local mail client.

6. Risks or unsafe questions

No blocking risks identified. Mail-client availability varies by browser/OS, so automated verification should assert the DOM link and target only. The change is safely implementable in an isolated preview without credentials, schema changes, migrations, or production operations.