feat: show a Sentry reference code on error pages

Closes #103.

Stack — 2 of 2. Sits on top of #108, which wires up the SDK this depends on.

(main) <- claude/sentry-python-sdk-setup-e45ee2 <- claude/sentry-error-pages

Review #108 first — this PR's diff is only the error pages.

Django's built-in error pages give a user nothing to quote and a developer no way to find the matching issue. These render the Sentry event ID of whatever was just captured, so "it broke, here's the code" is enough to pull up the request, the signed-in user, and the preceding log lines.

This completes the last requirement in #103 — the request ID on custom error pages.

What's here

• common/errors.py replaces the handler400/403/404/500 views.
• Standalone templates for 400, 403, 404, and 500, sharing templates/errors/base.html.

Why the pages are standalone

They deliberately do not extend the portal base template, which reads ServerSettings from the database. An error page has to render when the database is exactly what's broken — so there are no static files, no context processors, and no queries. A regression test asserts zero queries to keep it that way, in case someone later switches these back to render(request, ...).

When Sentry is disabled there is no event to reference, so the pages omit the reference block entirely rather than showing the user a code that would find nothing.

Verification

81 tests pass with the full stack applied (4 new here, covering status codes, the event ID appearing, its absence when Sentry is off, and the zero-query guarantee). manage.py check clean; ruff format --check and mypy clean.

🤖 Generated with Claude Code