Replace monolithic contacts table with 6 specialized person tables

[Copilot]

This PR implements a complete migration from the monolithic contacts table to 6 specialized, normalized person tables as requested in issue #230.

Overview

The existing contacts system stored all person-related data in a single table, making it difficult to manage privacy settings, track complex relationships, and maintain data integrity. This implementation replaces it with a normalized schema that provides better data organization and enhanced functionality.

New Person Tables Architecture

Core Tables

• person_profiles - Core profile information (name, gender, visibility, notes)
• person_contact_info - Email, phone, addresses with individual privacy settings
• person_professional_info - Job history, organizations, work details with reference tracking
• person_personal_info - Birthday, family information, emergency contacts, preferences
• person_life_events - Important dates, milestones with reminders and recurring patterns
• person_belongings - Items, gifts, possessions, borrowed items with full metadata
• person_relationships - Rich bidirectional relationship mapping (replaces contact_relationships)

Key Improvements

Privacy & Access Control

Each piece of information now has individual privacy settings (private/friends/public) rather than a single visibility flag for the entire contact.

# Before: Single visibility for entire contact
contact.visibility = "private"  # All or nothing

# After: Granular privacy control
contact_info.privacy_level = "public"    # Email can be public
personal_info.privacy_level = "private"  # Birthday stays private

Enhanced Life Event Tracking

The new system provides comprehensive life event management with reminders and recurring patterns:

life_event = PersonLifeEvent(
    event_type="birthday",
    event_date=date(1990, 1, 15),
    is_recurring=True,
    recurring_pattern="yearly",
    should_remind=True,
    reminder_days_before=7
)

Professional History Management

Complete job history tracking with references and skill management:

professional_info = PersonProfessionalInfo(
    job_title="Senior Engineer",
    organization_id=123,
    is_current_position=True,
    responsibilities=["Team lead", "Architecture"],
    skills_used=["Python", "FastAPI"],
    can_be_reference=True
)

API Changes

New Endpoints

• GET/POST /api/v1/persons/ - Person profile management
• GET/POST /api/v1/persons/{id}/contact-info - Contact information
• GET/POST /api/v1/persons/{id}/professional-info - Professional details
• GET/POST /api/v1/persons/{id}/personal-info - Personal information
• GET/POST /api/v1/persons/{id}/life-events - Life events
• GET/POST /api/v1/persons/{id}/belongings - Belongings tracking
• GET /api/v1/persons/upcoming-events/ - Upcoming events across all persons
• GET /api/v1/persons/emergency-contacts/ - Emergency contacts
• GET /api/v1/persons/borrowed-items/ - Borrowed items tracking

Legacy Compatibility

Existing /api/v1/contacts/ endpoints remain functional but are marked as DEPRECATED. This ensures zero downtime during migration.

Database Migration

The implementation includes two migration files:

1. 026_create_person_tables.py - Creates all new person tables with proper indexes and constraints
2. 027_migrate_contacts_to_persons.py - Migrates existing contact data to the new normalized structure

Data migration preserves all existing information while enhancing it with the new structure:

• Contact emails/phones → person_contact_info with privacy settings
• Job information → person_professional_info with enhanced tracking
• Personal details → person_personal_info with family context
• Birthdays/anniversaries → person_life_events with reminder system

Implementation Highlights

Backwards Compatibility

The system maintains full backwards compatibility during transition:

• Both old and new models coexist (388 total API routes)
• 23 legacy contact routes + 21 new person routes
• Existing functionality remains unchanged
• Migration can be performed with zero downtime

Data Integrity

• Comprehensive foreign key constraints
• Proper indexes for performance
• Tenant isolation maintained
• Audit trails preserved

Testing

Created comprehensive validation suite covering:

• Schema validation for all person models
• CRUD operations functionality
• API endpoint accessibility
• Migration file syntax validation
• Application startup with both old and new systems

Next Steps

After this PR is merged, the following steps will complete the migration:

1. Update foreign key references in related tables (gifts, events, tasks, etc.)
2. Remove legacy contacts table and endpoints
3. Update frontend to use new person endpoints

Fixes #230.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.