[bhuvanh66]

Summary

Adds a users table (one row per Google account) and a user_hotels link table, so users exist and can be linked to hotels. Storage only: no sign-in or auth yet. Closes #79.

Type of change

• feat — new feature
• fix — bug fix
• docs — documentation only
• refactor — code change that neither fixes a bug nor adds a feature
• perf — performance improvement
• test — adding or updating tests
• chore / build / ci — tooling, deps, or pipeline changes

Changes

This adds a users table with each person's Google account ID (unique), email, name, creation time and last sign-in time. A second table, user_hotels, links a user to a hotel. The user and hotel together form its primary key, so linking the same pair twice does nothing.

The model, repository and service layers can create a user, find one by Google ID or email, and link a user to a hotel idempotently. There are no routes. Until the app can link users itself, just link-user <email> <hotel_id> (in cli.py) does it from the command line.

The repository and service are covered by tests in tests/test_user.py. Decision 0032 records why the Google ID is the identity, and 0033 records how CLI commands work.

Database migrations

• No schema changes
• Includes an Alembic migration (just migrate-create "...")
• Migration runs cleanly (just migrate) and rolls back (just migrate-down)

Checklist

• Commits follow Conventional Commits
• Lint passes (just lint) and code is formatted (just format)
• Pre-commit hooks run clean (just hooks installed)
• Updated docs / README / .env.example where relevant
• Tested locally (just dev) and verified the API at http://localhost:8000/docs

How to test

1. just migrate, then just test
2. Insert a user and a hotel by hand (there's no sign-in yet), then run just link-user <email> <hotel_id> twice. Expect "Linked", then "already linked".

Notes for reviewers