refactor: rewrite ERP MCP server to FastMCP v3 with Google OAuth

[HusnainRazaGhaffar]

Summary

Complete rewrite of the ERP MCP server from raw MCP SDK to FastMCP v3 with native Google OAuth:

• FastMCP v3 framework — replaces hand-rolled MCP protocol handling with FastMCP(stateless_http=True) and native GoogleProvider for OAuth
• ERPClient refactor — extracted all ERP HTTP logic into a standalone ERPClient class with TTLCache (SHA-256 hashed keys, LRU eviction, TTL 15 min), per-key coalescing locks, and httpx async transport
• Write-path dual strategy — create_or_update_log uses PATCH on existing week logs or POST fallback, with project resolution via case-insensitive substring matching
• Security hardening — no email parameters on tools (identity from Google token only), domain restriction via hd claim, no HTTP redirects, no stack traces in responses, ERP token format validation, SecurityHeadersMiddleware
• 7 MCP tools — get_week_logs, get_logs_for_date_range, create_or_update_log, delete_log, fill_logs_for_days, get_active_projects, check_person_week_project_exists
• 149 passing tests — full coverage of ERPClient (respx-mocked HTTP), server tools (mocked ERPClient), TTLCache, and security controls
• CI/CD pipeline — GitHub Actions with lint (ruff), type check (mypy), test, Docker build, Trivy vulnerability scanning, and ECR push (OIDC, no long-lived credentials)

Deleted: main.py, tools/, utils/, auth/, services/ — the entire legacy module tree replaced by server.py + erp_client.py

Context

The legacy server used raw MCP SDK with a custom OAuth implementation spread across multiple modules. This rewrite consolidates everything into two files (server.py for tool definitions and OAuth, erp_client.py for ERP API communication) using FastMCP v3's built-in patterns. The ERP API contract is unchanged — this is a transport and framework rewrite, not a backend change.

[NIXKnight]

[💡 Suggestion]: _exchange_locks dict grows unboundedly

Every unique Google token adds an asyncio.Lock to self._exchange_locks that is never removed. Over the lifetime of the process, this dict accumulates one entry per distinct cache_key (SHA-256 hash). While the TTLCache evicts stale tokens, the corresponding locks remain forever.

In a long-running single-worker deployment this is a slow memory leak. Consider cleaning up locks after use, or use a bounded TTLCache for locks as well:

Suggested fix:

# Option A: clean up after use
async with lock:
    ...  # existing logic
# After releasing the lock, remove it if no one else is waiting
if not lock.locked():
    self._exchange_locks.pop(cache_key, None)

# Option B: use setdefault (more idiomatic, still needs cleanup)
lock = self._exchange_locks.setdefault(cache_key, asyncio.Lock())

[NIXKnight]

[💡 Suggestion]: resolve_label_id silently falls back to default label on API failure

When a user provides label_name but the get_log_labels API call fails, this method returns None (line 1130). The caller in create_or_update_log then substitutes _DEFAULT_LABEL_ID, silently ignoring the user's label preference.

The user explicitly asked for a specific label but gets the default without any warning. Consider raising a ValueError instead, consistent with how resolve_project_id handles API failures (line 1076).

Suggested fix:

result = await self.get_log_labels(token)
if result.get("status") != "success":
    raise ValueError(
        f"Failed to fetch log labels (cannot resolve '{label_name}'): "
        f"{result.get('message')}"
    )

[NIXKnight]

See inline comments for details.