[P1] Add database constraints and indexes for core data integrity

[jjoonleo]

Problem

Several database invariants are enforced only in application code or not enforced at all. The schema allows duplicate users/places/social identities and nullable fields that business logic appears to require.

Why this is not production ready

Application-only uniqueness checks are race-prone. Missing database constraints allow duplicate accounts, ambiguous login behavior, corrupt schedules, and data that crashes service logic later.

Evidence

• user.email, user.name, and social identity fields have no unique constraints in V1__init.sql.
• PlaceRepository.findByPlaceName assumes place names can identify a place, but place.place_name has no unique constraint.
• Many business-required fields are nullable in migrations/entities, including user role, schedule time, tokens, and settings-related values.
• friend_ship stores requester_id and receiver_id as scalar IDs instead of proper JPA relationships in the entity, while SQL has foreign keys.
• UserAuthService.signUp checks duplicate email/name before save, but concurrent requests can still race without DB constraints.

Required work

• Define the canonical uniqueness rules for local email, social provider identity, name, place, device, and friendship relationships.
• Add Flyway migrations for unique constraints, indexes, and not-null constraints after cleaning existing data.
• Align JPA entities with database constraints.
• Convert scalar friendship IDs to explicit relationships if appropriate, or document why the scalar design is intentional.
• Add tests for duplicate signup/social login/place/friendship races where feasible.

Acceptance criteria

• Duplicate local emails and duplicate provider identities cannot be inserted even under concurrent requests.
• Required domain fields are non-null at the database layer.
• Existing data migration/cleanup is documented.
• Tests cover duplicate insert failures and expected error mapping.