Add Sentry error monitoring

[ChiragAgg5k]

Summary

• add hosted HTTP-only Sentry initialization behind SENTRY_DSN
• capture unexpected MCP/Appwrite failures with low-cardinality tags and duplicate suppression
• scrub sensitive request/event fields and keep Appwrite 4xx/user errors out of Sentry
• document local config and add Compose/env example placeholders

Testing

• uv run python -m unittest discover -s tests/unit -v
• uv run --group dev ruff check src tests
• uv run --group dev black --check src tests
• uv run --group dev pyright

[greptile-apps]

Greptile Summary

This PR adds opt-in Sentry error monitoring for the hosted HTTP transport, gated behind SENTRY_DSN. It introduces error_monitoring.py with sensitive-field scrubbing, 4xx/ValueError suppression, and a chain-walking deduplication mechanism, then wires capture calls into all existing exception handlers in server.py.

• error_monitoring.py is a well-scoped new module: Sentry is initialized lazily (only when SENTRY_DSN is set and transport is "http"), sentry_sdk is only imported inside functions so stdio users pay no import cost, and _mark_captured / _already_captured prevent double-reporting when a 5xx AppwriteException is re-wrapped into a RuntimeError.
• _sanitize recursively scrubs the full Sentry event before send, correctly filtering X-Appwrite-Key headers (the normalized form x_appwrite_key is now in _SENSITIVE_KEYS) and blocking data/body/arguments keys at any nesting depth.
• Test coverage is thorough, including no-DSN/stdio no-ops, 4xx suppression, 5xx dedup, tag/context forwarding, and redaction of sensitive headers.

Confidence Score: 5/5

Safe to merge — monitoring is strictly opt-in, disabled for stdio, and all capture paths are exception-safe so Sentry activity can never affect request behavior.

The change is additive and well-isolated: Sentry is only initialized when SENTRY_DSN is explicitly configured on an HTTP transport, sensitive-field scrubbing is correct (including the normalized x_appwrite_key form), and the deduplication logic correctly prevents double-reporting through wrapped exception chains. Both the core module and its call sites are covered by unit tests. No existing behavior is altered for users who do not set SENTRY_DSN.

No files require special attention.

Important Files Changed

Filename	Overview
src/mcp_server_appwrite/error_monitoring.py	New module implementing Sentry error monitoring with sensitive-field scrubbing, 4xx suppression, and duplicate-capture prevention; logic is correct and the previously reported x-appwrite-key normalization bug is fixed.
src/mcp_server_appwrite/server.py	Integrates error_monitoring capture calls at every existing exception handler; AppwriteException 5xx path, generic internal path, and MCP handler paths are all correctly wired up with deduplication via _mark_captured / _already_captured.
src/mcp_server_appwrite/http_app.py	Adds init_error_monitoring call before telemetry init in build_app; correctly scoped to HTTP transport only.
tests/unit/test_error_monitoring.py	Good unit coverage: no-DSN / stdio no-op, 4xx suppression, 5xx dedup, tag/context propagation, and sensitive-field redaction including X-Appwrite-Key.
tests/unit/test_server.py	Three new integration-style tests verify AppwriteException, target-context forwarding, and generic RuntimeError capture paths; all use appropriate mocking.
pyproject.toml	sentry-sdk[starlette]>=2.0 added as a mandatory (not optional) runtime dependency; the SDK is only lazily imported inside functions, so stdio users incur no import cost.
.env.example	Adds SENTRY_DSN and SENTRY_ENVIRONMENT comment examples, consistent with other optional variables.
compose.yaml	Passes SENTRY_DSN and SENTRY_ENVIRONMENT through to the container; SENTRY_ENVIRONMENT defaults to 'development', which is safe.

_{Reviews (2): Last reviewed commit: "Enrich Sentry error context" | Re-trigger Greptile}