feat: scope candidate profile uniqueness

[pashawkola33]

Summary

• make candidate_profiles.profile_version unique per candidate instead of installation-wide
• allow one active candidate profile per candidate by scoping active_slot uniqueness to candidate_id
• add defensive Flyway V15 Java migration that discovers the historical generated constraint names on both PostgreSQL and H2 before replacing them
• schema-qualify V15 DDL and provide a deterministic Flyway checksum for the Java migration
• remove the stale JPA global uniqueness declaration and update candidate-profile architecture documentation
• preserve V14 historical behavior in its migration test and add focused V15 upgrade/fresh-schema coverage

Database invariants after V15

• different candidates may reuse the same profile_version
• a candidate cannot reuse one of its own profile versions
• different candidates may each have one active profile
• a candidate cannot have two active profiles
• existing candidate ownership, profile IDs/history, candidate_id NOT NULL, ON DELETE RESTRICT, and active_slot consistency semantics remain unchanged

Validation

• ./mvnw -Dtest=V14CandidateOwnershipMigrationTest,V15CandidateProfileScopedUniquenessMigrationTest test
• ./mvnw -Dtest=CandidateProfileBootstrapServiceTest,CandidateProfileBootstrapIntegrationTest test
• ./mvnw -Dtest=JobAnalysisServiceTest,ResumeGenerationServiceTest test
• ./mvnw -Dtest=PostgresPersistenceIT test
• ./mvnw verify
• git diff --check

Full verification passed locally. PostgreSQL integration tests ran against PostgreSQL 16 via Testcontainers.

Deliberately out of scope

JobAnalysisService and ResumeGenerationService still use the legacy installation-wide findByActiveTrue() lookup. Candidate context propagation into those workflows is intentionally deferred to a later multi-user phase. This PR does not scope job_scores or job_workflow_state, and does not change ingestion, CV, auth, Telegram, deployment, or Azure behavior.