feat: Implement chat auto-reply feature

This commit introduces an autoreply feature for WhatsApp messages.

Key changes:

1.  **Database Schema:**
    *   Added `last_sent_at` (TIMESTAMP) column to the `autoreplies` table to track the last time an autoreply was sent.
    *   Updated `migrations.go` to include this new column.

2.  **API Endpoints & Handlers:**
    *   Added a new `GET /chat/autoreply` endpoint to list all configured autoreplies for you.
    *   Created `GetAutoReplies` handler in `handlers.go`.
    *   Modified `AddAutoReply` in `handlers.go` to initialize `last_sent_at` to NULL.
    *   Updated `routes.go` to map the new GET endpoint.

3.  **Autoreply Logic:**
    *   Implemented the core autoreply logic in `wmiau.go` within the `myEventHandler`.
    *   When a message is received, the system checks if an autoreply rule exists for the sender.
    *   An autoreply is sent if a rule exists and if no reply has been sent to that number in the last 5 minutes.
    *   The `last_sent_at` timestamp is updated after an autoreply is sent.

4.  **API Documentation:**
    *   Updated `static/api/spec.yml` to include the new `GET /chat/autoreply` endpoint and its response schema (`AutoReplyEntry`).

This feature allows you to configure automatic replies to incoming messages with a 5-minute cooldown period per recipient.

feat: Implement WhatsApp autoreply feature

add references

Utility class to add user

This commit introduces a new "modes" system for managing autoreplies. You can define different modes (e.g., "work", "home") with specific phone numbers and autoreply messages associated with each mode.

Key features include:

1.  **Database Changes:**
    *   Added `autoreply_modes` table to store mode configurations (user_id, mode_name, phone_number, message).
    *   Added `active_mode` table to track the currently active mode for each user.

2.  **New API Endpoints (under /mode/):**
    *   `POST /mode/autoreply`: Add or update a phone number and message for a specific mode.
    *   `DELETE /mode/autoreply`: Delete a phone number from a mode, or delete an entire mode.
    *   `GET /mode/autoreply`: Retrieve configured phone numbers and messages for a mode or all modes.
    *   `POST /mode/enablemode`: Activate a mode, clearing previous autoreplies and applying the selected mode's configuration.
    *   `POST /mode/disablemode`: Deactivate the currently active mode, clearing relevant autoreplies.
    *   `GET /mode/currentmode`: Get the name of the currently active mode.
    *   `POST /mode/clear`: Clear all active autoreplies and deactivate any current mode.

3.  **API Spec Update:**
    *   Updated `static/api/spec.yml` to include definitions for all new `/mode/...` endpoints.

4.  **Unit Tests:**
    *   Added a comprehensive test suite in `handlers_mode_test.go` to cover the new API handlers, ensuring functionality and user-specificity.

This system allows you to easily switch between different sets of autoreply configurations. Mode names are stored in lowercase and must be alphanumeric.

This commit introduces a comprehensive autoreply mode management system and integrates with Google Contacts for populating modes.

Key features:

1.  **Autoreply Modes Management (Phase 1):**
    *   New `autoreply_modes` table to store mode configurations (mode name, phone number, message) per user.
    *   New `active_mode` table to track the currently active mode per user.
    *   API Endpoints:
        *   `POST /mode/autoreply`: Add/update a phone number and message to a mode.
        *   `DELETE /mode/autoreply`: Delete a phone number from a mode or an entire mode.
        *   `GET /mode/autoreply`: List configured autoreplies for a mode or all modes.
        *   `POST /mode/enablemode`: Activate a mode, loading its numbers into the live autoreply list.
        *   `POST /mode/disablemode`: Deactivate the current mode.
        *   `GET /mode/currentmode`: View the currently active mode.
        *   `POST /mode/clear`: Clear all active autoreplies.
    *   Mode names are stored in lowercase and validated (alphanumeric).
    *   Comprehensive unit tests for all mode management handlers.
    *   OpenAPI specification updated for all new mode endpoints.

2.  **Google Contacts Integration (Phase 2):**
    *   `users` table updated with `google_contacts_auth_token` column to store user-provided OAuth tokens.
    *   API Endpoints:
        *   `POST /autoreply/contactgroupauth`: Store Google Contacts API auth token for you.
        *   `POST /autoreply/contactgroup`: Fetch contacts from a (mocked) Google Contacts group using the stored token, normalize phone numbers, and add them to a specified autoreply mode.
        *   `DELETE /autoreply/contactgroup`: Fetch contacts from a (mocked) Google Contacts group, normalize phone numbers, and remove them from a specified autoreply mode.
    *   Implemented robust phone number normalization logic (handles '+' prefix, default country code '91').
    *   Google Contacts API interaction is currently via a placeholder function (`fetchContactsFromGoogleGroup`) to allow testing of the surrounding logic.
    *   Unit tests for new handlers, including token management, phone normalization, and mocked API interaction.
    *   OpenAPI specification updated for Google Contacts integration endpoints.

All database schema changes are handled idempotently. All new endpoints are covered by authentication middleware.

This commit replaces the placeholder implementation of
`fetchContactsFromGoogleGroup` with live HTTP calls to the Google
People API.

Key changes:
- `fetchContactsFromGoogleGroup` now:
  - Fetches all contact groups for the authenticated user to find the
    `resourceName` of the target group by its display name.
  - Fetches all connections (contacts) for `people/me`, requesting
    names, phone numbers, and memberships.
  - Filters connections to find members of the target group.
  - Extracts names and phone numbers of group members.
  - Handles pagination for API calls.
  - Includes the OAuth2 token in `Authorization: Bearer` headers.
  - Defines structs for parsing Google People API JSON responses.
- Enhanced error handling:
  - `fetchContactsFromGoogleGroup` attempts to parse Google's JSON
    error responses to return more specific error messages.
  - Calling handlers (`AddContactGroupToMode`, `DeleteContactGroupFromMode`)
    inspect these errors to return appropriate HTTP status codes
    (403, 404, 500) and user-friendly messages.
  - Improved handling of cases where no contacts are found in a group.
- Unit tests in `handlers_mode_test.go` updated:
  - `fetchContactsFromGoogleGroupFunc` is now a package-level variable,
    allowing it to be mocked effectively during tests.
  - Tests now cover the new error handling paths and ensure correct
    handler behavior based on various (mocked) outcomes from
    `fetchContactsFromGoogleGroupFunc`.

This commit refactors the API paths for mode management and consolidates Swagger tags for all autoreply-related features.

Changes:
- **URL Refactoring:**
  - `/mode/autoreply` (POST, GET, DELETE) moved to `/autoreply/mode`.
  - `/mode/enablemode` moved to `/autoreply/enablemode`.
  - `/mode/disablemode` moved to `/autoreply/disablemode`.
  - `/mode/currentmode` moved to `/autoreply/currentmode`.
  - `/mode/clear` moved to `/autoreply/clearmode`.
  These changes are reflected in `routes.go`.

- **Swagger Spec Updates (`static/api/spec.yml`):**
  - Paths updated to match the new URL structure.
  - Removed `Mode` and `Autoreply Contacts` global tag definitions.
  - Added/updated a single `Autoreply` global tag.
  - All mode management endpoints (now under `/autoreply/...`),
    Google Contacts integration endpoints (`/autoreply/contactgroup...`),
    and simple autoreply endpoints (`/chat/autoreply...`) are now
    grouped under the `Autoreply` tag in Swagger.

- **Unit Tests:**
  - Endpoint URLs in `handlers_mode_test.go` updated to match the
    new `/autoreply/...` paths.

The handlers.go file used io.ReadAll without importing the "io"
package, specifically within the fetchContactsFromGoogleGroupFunc
when handling HTTP error responses from the Google People API.
This caused an "undefined: io" compilation error.

This commit adds "io" to the import block in handlers.go to resolve
the issue.

This commit resolves an issue where ALTER TABLE and CREATE TABLE statements
for custom features (google_contacts_auth_token, autoreply_modes, active_mode)
were attempted before the core `users` table was created by migrations.
This led to "no such table: users" errors.

Changes:
- Moved the addition of the `google_contacts_auth_token` column to the
  `users` table into a new migration (ID 5) in `migrations.go`.
- Moved the creation of the `autoreply_modes` table into a new
  migration (ID 6) in `migrations.go`.
- Moved the creation of the `active_mode` table into a new
  migration (ID 7) in `migrations.go`.
- Removed these DDL operations from the `createTables` function in `db.go`.
  The `createTables` function is now a no-op for these specific tables.
- Ensured platform-specific SQL (PostgreSQL and SQLite) is used within
  the migrations for conditional table/column creation (IF NOT EXISTS).

This ensures that all schema setup, including these new tables and columns,
is handled by the migrations system in the correct order, after the
`users` table is guaranteed to exist.

The "strings" package was previously imported in db.go to support
`strings.Contains` for conditional ALTER TABLE logic for SQLite.
This logic has since been moved into the migrations system (`migrations.go`).

As a result, the "strings" import is no longer used in `db.go` and
has been removed to prevent "imported and not used" build errors.

…Info()` without the necessary import for the logging package ("github.com/rs/zerolog/log"), which led to an "undefined: log" compilation error. I've now added the "log" import to migrations.go to fix this.

A duplicate mapping key for "AutoReplyEntry" existed in the
`definitions` section of `static/api/spec.yml`, causing a YAML
parsing error.

This commit removes the second, redundant definition of
`AutoReplyEntry`, leaving the first occurrence intact.

This commit further modularizes the codebase by separating
Google Contacts integration logic from the more general autoreply
handlers and types.

Key changes:

- **`google_contacts_types.go`:**
  - New file created.
  - Contains struct definitions specifically for Google Contacts API
    interaction and the `/autoreply/contactgroup...` endpoints.
    These include `AuthTokenRequest`, `ContactGroupRequest`,
    `ContactGroupDeleteRequest`, and all `Google...` API response
    parsing structs (e.g., `GooglePerson`, `GoogleApiError`).
    These were moved from `autoreply_types.go`.

- **`google_contacts_integration.go`:**
  - New file created.
  - Contains handler functions for Google Contacts:
    `SetGoogleContactsAuthToken`, `AddContactGroupToMode`,
    `DeleteContactGroupFromMode`.
  - Helper functions specific to this integration:
    `fetchContactsFromGoogleGroupFunc` (and its implementation) and
    `normalizePhoneNumber` also moved here.
    These were moved from `autoreply_handlers.go`.

- **`autoreply_types.go`:**
  - Cleaned up by removing the Google Contacts specific structs. Now
    primarily contains types for mode management and simple autoreply.

- **`autoreply_handlers.go`:**
  - Cleaned up by removing the Google Contacts specific handlers and
    helpers. Now contains handlers for mode management and simple
    autoreply, and the `isValidModeName` helper.

- **`autoreply_routes.go`:**
  - No changes were needed in this file, as the method signatures
    on the `*server` type remain consistent, and the router correctly
    locates them regardless of the source file within `package main`.

All new and modified files maintain `package main` and have updated
imports as necessary. This refactoring enhances modularity and aims
to reduce potential merge conflicts.

This commit addresses syntax errors in `autoreply_handlers.go` and
`handlers.go` that were reported as "non-declaration statement
outside function body".

These errors were due to file content duplication or extraneous code
likely introduced during previous refactoring steps. I have corrected the files to contain only their intended, valid Go code.

- `autoreply_handlers.go`: I ensured the file contains only one set of its
  definitions, removing any duplicated content.
- `handlers.go`: I rewrote this file to ensure it only contains the core handlers
  and helpers after other functionalities were moved to separate files.
  This also resolves any potential duplication or extraneous code.

This commit addresses several build errors related to function redeclarations
and incorrect function/method usage.

Consolidations:
- `Find` function: Canonical version (returning int, bool) now resides in
  `helpers.go`. Removed from `handlers.go`.
- `updateUserInfo` function and `Values` struct: Moved to `helpers.go`.
  Removed from `handlers.go`. The version in `helpers.go` is type-safe.
- `respondWithJSON` server method: Ensured it is solely defined in
  `handlers.go`. Removed duplicate from `helpers.go`.
- `parseJID` function: Canonical version now resides in `wmiau.go`.
  Removed from `handlers.go`.

Usage Corrections in `handlers.go`:
- `Find` function calls: Corrected calls in the `Connect` handler (lines
  ~152, 157, 161) to properly handle the (int, bool) return type,
  resolving "multiple-value in single-value context" errors.
- `updateUserInfo` calls: Corrected type assertions for the `userinfo`
  context value when calling `updateUserInfo` (lines ~172, 226, 301),
  changing `r.Context().Value("userinfo")` to
  `r.Context().Value("userinfo").(Values)`.

Import Cleaning:
- Unused imports that resulted from these consolidations (e.g., in
  `helpers.go`) were removed.

Note on Code Structure:
This commit focuses on resolving the immediate build errors. You provided feedback requesting that `handlers.go` be aligned as closely as
possible with the upstream repository (github.com/asternic/wuzapi/blob/main/handlers.go)
to minimize future merge conflicts. The refactoring work that moved
autoreply and Google Contacts related handlers out of `handlers.go` into
separate files (`autoreply_handlers.go`, `google_contacts_integration.go`,
etc.) may need to be revisited or reverted in future work to achieve this
alignment goal. The helper function consolidations in this commit are a
step towards reducing direct conflicts but the broader structure of `handlers.go`
(i.e., which functions it contains) is the main point of your feedback
for future consideration.

… done so far and provide feedback for Jules to continue.

…nment

This commit reverts previous modularization efforts (splitting autoreply
and Google Contacts features into separate files) and consolidates all
handler logic, type definitions, and relevant helpers back into
`handlers.go`. This is done to align the codebase structure more
closely with the upstream repository (asternic/wuzapi) and minimize
future merge conflicts, as per your feedback.

Specific changes:
- All struct definitions from `autoreply_types.go` and
  `google_contacts_types.go` were moved back to `handlers.go`.
  The `_types.go` files were removed.
- All handler functions and their private helpers from
  `autoreply_handlers.go` and `google_contacts_integration.go`
  were moved back to `handlers.go`. The separate handler files
  were removed.
- Route definitions from `autoreply_routes.go` were moved back into
  the main `routes()` function in `routes.go`. The
  `autoreply_routes.go` file was removed, and the call to its
  registration function was removed from `routes.go`.

Helper function consolidation:
- `Values` struct and `updateUserInfo` function (with signature
  accepting `interface{}` for context value) are now in `handlers.go`,
  aligning with upstream. Removed from `helpers.go`.
- `Find` function (returning `int, bool`) remains in `helpers.go` as
  it's not present in upstream `handlers.go`.
- `parseJID` function remains in `wmiau.go`.
- `s.Respond` is used as the primary response method in `handlers.go`.

Error corrections:
- Corrected usage of `Find` in `handlers.go` (in `Connect`,
  `UpdateWebhook`, `SetWebhook`, `AddUser` handlers) to properly
  handle its two return values.
- Corrected calls to `updateUserInfo` in `handlers.go` to pass
  the context value directly, as the function now handles type assertion.
- Created `constants.go` for `supportedEventTypes` (formerly `messageTypes`)
  as per upstream structure, and updated references.

Imports were reviewed and cleaned in all affected files.
This set of changes aims to make the codebase structure, particularly
`handlers.go`, more similar to the upstream repository.

This commit resolves "s.respondWithJSON undefined" errors in `handlers.go`.

Changes:
- The `s.Respond` method was updated to be more versatile in handling
  different `data` payload types (error, map, pre-marshalled JSON string,
  other types, nil), and to log JSON encoding errors instead of panicking.
- All calls to the old `s.respondWithJSON` method (primarily in admin
  user handlers like `AddUser`, `DeleteUser`) were replaced with calls
  to the updated `s.Respond` method, including passing the necessary
  `r *http.Request` argument.

This ensures consistent JSON response formatting and error handling across
the application.