Add contributor and agent guidance documentation

[shenanigansd]

Summary

This PR adds comprehensive documentation for contributors and AI coding agents working on mundane-backend. These new files establish clear guidelines for development workflow, code style, architecture boundaries, and project setup.

Key changes

• CONTRIBUTING.md: A contributor-focused guide covering prerequisites, local setup, development workflow, checks to run before pushing, code style expectations, architecture boundaries to respect, testing practices, documentation updates, dependency management, and security reporting.

• AGENTS.md: A detailed guide for AI coding assistants (e.g., GitHub Copilot) with project overview, setup instructions, build/run/test commands, linting and formatting details, code style rules, architecture and layout, key invariants to preserve (engine/API separation, the apply_action single door, tagged union actions), gotchas (Litestar 3 pre-release status, CI resolution strategy, GitHub Actions security), and a pointer to human-focused docs.

• .github/copilot-instructions.md: Copilot-specific guidance emphasizing code review priorities (layering, the one door, illegal move handling, action schemas, types/docs, style, tests, dependencies, Litestar 3 status) and code generation best practices.

• .github/ISSUE_TEMPLATE/bug_report.yml: Structured bug report template with fields for description, reproduction steps, expected behavior, environment, and logs; includes a note that rules and cards are in the meta repo.

• .github/ISSUE_TEMPLATE/feature_request.yml: Structured feature request template with fields for problem/motivation, proposed solution, alternatives, and context; directs rules/card changes to the meta repo.

• .github/ISSUE_TEMPLATE/config.yml: Issue template configuration disabling blank issues and providing contact links to the meta repo (for rules/cards) and documentation site.

• .github/PULL_REQUEST_TEMPLATE.md: PR template with a summary section, related issues field, and a checklist covering linting, testing, docs, dependencies, and architecture boundaries.

Notable implementation details

• All documentation emphasizes the core architectural principle: engine has no HTTP knowledge; API is the only HTTP layer. This boundary is highlighted repeatedly across all guides.
• The apply_action function in engine/rules.py is established as "the one door" through which all state changes must pass.
• Clear separation of concerns: rules and cards spec live in the meta repo; this repo is the engine and API implementation.
• Specific tool versions and configurations are documented (Python 3.14+, uv >= 0.11.8, Litestar 3 from git main, ruff with line-length = 120 and select = ["ALL"], mypy --strict).
• Issue templates and PR template guide contributors toward the right repository for different types of changes.

https://claude.ai/code/session_013SBs3pqpzAqQWuaExZfEzc