<type>: <concise description of what changed>

Bad:  "Updates"
Good: "feat: add full-text search to user directory"

Bad:  "Fix bug"
Good: "fix: prevent duplicate charge on payment retry"

Bad:  "Refactoring the auth module and also fixing some tests and updating docs"
Good: "refactor: extract token validation into dedicated service"

## Summary

A 1-3 sentence overview of what this PR does and why. This should be understandable
by someone who has not read the code.

## Motivation

Why is this change needed? Link to the issue, bug report, or product requirement
that motivated this work.

Closes #123

## Changes

A bulleted list of the specific changes made:

- Added `SearchService` class with full-text query support
- Created `/api/users/search` endpoint with pagination
- Added search index migration for the users table
- Updated API documentation with new endpoint

## Test Plan

How was this change tested? Be specific.

- [ ] Unit tests for `SearchService` covering empty queries, partial matches, and pagination
- [ ] Integration test for the search endpoint with test database
- [ ] Manual testing: verified search returns expected results in staging
- [ ] Load tested with 10k users in the index

## Screenshots / Recordings

If the change has a visual component, include before/after screenshots or a screen
recording. For API changes, include example request/response pairs.

**Before:**
(screenshot or N/A)

**After:**
(screenshot or N/A)

## Notes for Reviewers

Any additional context that will help reviewers:

- I chose cursor-based pagination over offset because [reason]
- The migration is backward-compatible and can be rolled back
- This depends on PR #456 being merged first

## Checklist

- [ ] Tests pass locally
- [ ] Code follows project style guidelines
- [ ] Documentation updated if needed
- [ ] No secrets or credentials included
- [ ] Migration is reversible (if applicable)
- [ ] Breaking changes documented (if applicable)

## Summary

Fix null pointer exception when user profile has no avatar set.

Closes #789

## Changes

- Added null check in `UserProfile.getAvatarUrl()`
- Added test case for users without avatars

## Test Plan

- [x] Unit test added for the null avatar case
- [x] Existing tests pass

Closes #123
Fixes #456
Resolves #789

Closes org/other-repo#123

Related to #123
Part of #456
See also #789

## Status

Done:
- [x] Database schema and migration
- [x] Repository layer

Remaining:
- [ ] Service layer business logic
- [ ] API endpoint
- [ ] Tests

## What I Need Feedback On

- Is the schema design appropriate for the query patterns we expect?
- Should we use a separate table for search metadata?

PR #1: feat: add user search database schema
  └── PR #2: feat: add search service with query logic
       └── PR #3: feat: add search API endpoint and docs

## Stack

This is PR 2 of 3 in the search feature stack:
1. #100 - Database schema (merged)
2. **#101 - Search service (this PR)**
3. #102 - API endpoint (draft, depends on this PR)

# PR 1
git checkout -b feature/search-schema

# PR 2 (based on PR 1)
git checkout -b feature/search-service feature/search-schema

# PR 3 (based on PR 2)
git checkout -b feature/search-endpoint feature/search-service

# Make changes on PR 1's branch
git checkout feature/search-schema
# ... make changes, commit ...

# Rebase PR 2 onto updated PR 1
git checkout feature/search-service
git rebase feature/search-schema

# Rebase PR 3 onto updated PR 2
git checkout feature/search-endpoint
git rebase feature/search-service

# Force-push all updated branches
git push --force-with-lease origin feature/search-schema
git push --force-with-lease origin feature/search-service
git push --force-with-lease origin feature/search-endpoint

## Review Response

- **[Comment about error handling]** Fixed -- added try/catch with proper logging in abc123
- **[Comment about naming]** Renamed `processData` to `validateAndStorePayment` in def456
- **[Comment about test coverage]** Added edge case tests for empty input in ghi789
- **[Comment about architecture]** I'd prefer to keep this in a single service for now --
  the traffic doesn't justify the complexity of splitting. Happy to discuss further.

# feat: add cursor-based pagination to user search endpoint

## Summary

Replaces the offset-based pagination on `/api/users/search` with cursor-based
pagination to handle our growing user base without performance degradation.

## Motivation

The user directory now has 2M+ records. Offset pagination causes increasingly
slow queries at high page numbers because the database must scan and discard
rows. Cursor-based pagination maintains constant performance regardless of
position.

Closes #1234

## Changes

- Replaced `page` and `per_page` params with `cursor` and `limit`
- Added `next_cursor` and `has_more` to response envelope
- Updated `UserRepository.search()` to use keyset pagination on `(created_at, id)`
- Added database index on `(created_at, id)` for the users table
- Marked old `page` parameter as deprecated with warning header
- Updated API docs with new pagination format

## Test Plan

- [x] Unit tests for cursor encoding/decoding
- [x] Integration tests verifying correct page traversal over 1000 records
- [x] Verified backward compatibility: requests with `page` param still work (with deprecation warning)
- [x] Load test: p99 latency at page 10000 dropped from 2.3s to 45ms

## Notes for Reviewers

- The cursor is a base64-encoded JSON of `{created_at, id}` -- intentionally opaque to clients
- Old `page` parameter will be removed in v3.0 (tracked in #1235)
- Migration `20240115_add_users_pagination_index.sql` is safe to run on production without downtime