feat: add candidate ownership to profiles

[pashawkola33]

Summary

• add a minimal persistent Candidate owner with a stable configured key
• make every CandidateProfile explicitly belong to a candidate
• migrate existing profile history to the seeded default candidate via Flyway V14
• scope candidate bootstrap lookups by candidate identity while preserving current single-candidate runtime behavior

Migration

V14__candidate_ownership.sql:

• creates candidates
• seeds stable_key = 'default'
• adds and backfills candidate_profiles.candidate_id
• makes candidate_id mandatory
• adds FK candidate_profiles_candidate_fk with ON DELETE RESTRICT
• adds index candidate_profiles_candidate_idx

This migration intentionally does not change the existing global uniqueness of candidate_profiles.profile_version or active_slot; those remain a known single-candidate limitation for a dedicated follow-up.

Compatibility

• existing candidate facts are unchanged
• candidate-key is excluded from the candidate facts source hash, so ownership does not invalidate stored profile fingerprints
• scoring, job_scores, ingestion, rescore, workflow, Mini App, Telegram, LLM behavior, and resume semantics are unchanged

Validation

• 41 focused tests passed
• 0 failures, 0 errors, 0 skipped
• V14 tested for both existing-profile backfill and fresh-database migration using H2/Flyway
• JPA schema validation passed in the candidate bootstrap integration tests
• git diff --check clean
• no Docker, production DB, manual SQL, or rescore commands were used

Follow-up

A separate Phase 2.2 change will replace the remaining global profile_version and active_slot uniqueness constraints with candidate-scoped constraints so multiple candidates can each have their own active/versioned profiles.