[codex] Add custom open-to-work contact email

[B-EtterDigital]

Summary

• Add an optional custom contact email to open-to-work profiles.
• Validate/normalize the email in a shared helper and API route.
• Store the email in a nullable profiles.open_to_work_email column and clear it when opting out.
• Show email contact actions on /hire when an opted-in engineer has saved an email, falling back to GitHub contact otherwise.
• Harden mailto: links against query/header injection and encode mailto components.
• Add an accessible label to the owner contact email input.

Migration

• Adds supabase/migrations/005_open_to_work_email.sql with nullable open_to_work_email, an email-format check constraint, and a DB invariant that email is only stored when open_to_work is true.
• supabase db push was attempted locally but blocked because this checkout is not linked to a Supabase project ref: Cannot find project ref. Have you run supabase link?

Validation

• pnpm test passes on this branch: 19 ccusage tests and 9 open-to-work tests.
• Combined merge simulation for PRs [codex] Fix leaderboard sorting, timelines, and duplicate claims #72, [codex] Add expandable profile model list #73, [codex] Make profile rank more prominent #74, [codex] Add custom open-to-work contact email #75 passes pnpm test: 19 ccusage + 9 open-to-work + 10 model-list + 6 rank + 19 site-bug tests.
• Combined production build passes in a temp worktree with dummy auth/Supabase env values.
• git diff --check passes.

Scope

Feature-only PR. It intentionally does not include PR #72 bug fixes, PR #73 expandable model list changes, or PR #74 rank presentation changes.

[vercel]

@B-EtterDigital is attempting to deploy a commit to the sculpt Team on Vercel.

A member of the Team first needs to authorize it.

[nikshepsvn]

Sorry this sat for seven weeks. Still wanted — and the conflict is much smaller than the "this branch has conflicts" banner suggests. I test-merged it against current main: the only conflicting file is package.json, and only the test script line, because several PRs in this batch each append to it.

One real blocker to fix while you're rebasing, though:

Migration number collision. This adds supabase/migrations/005_open_to_work_email.sql, but main already has 005_machine_contributions.sql. Please renumber to 009_ — main is currently up to 008_site_stats_monthly_tiers.sql.

Also note main already has 003_open_to_work.sql adding the open_to_work boolean, so your migration should be purely additive on top of that rather than redefining it.

Heads up that #100 just landed a fair amount of change in src/lib/data/supabase/client.ts and src/lib/data/types.ts, both of which this PR touches — worth rebasing after that merges rather than before, to avoid doing it twice.