docs: add comprehensive documentation and GitHub standard files

[terraboops]

Add complete documentation suite for the project:

• README.md: Clean project overview with quick start guide
• CONTRIBUTING.md: Contributor guidelines with coding standards
• CODE_OF_CONDUCT.md: Community code of conduct
• SECURITY.md: Security policy and vulnerability reporting
• docs/getting-started.md: Installation and first steps
• docs/architecture.md: System design and component overview
• docs/configuration.md: Configuration reference
• docs/protocol-support.md: XMPP XEP coverage details
• docs/deployment.md: Production deployment guide
• .github/PULL_REQUEST_TEMPLATE.md: PR template
• .github/ISSUE_TEMPLATE/bug_report.md: Bug report template
• .github/ISSUE_TEMPLATE/feature_request.md: Feature request template

[terraboops]

Voice & Style Review

This docs PR reads like it was generated by an AI following a template. Several patterns clash with how you actually write:

AI Buzzwords to Remove

These words appear throughout and should be replaced with plain language:

• "comprehensive" (appears 3x) - just say what it covers
• "seamless" (CONTRIBUTING.md) - delete or replace
• "robust" (not found, but the style leans that direction)
• "enables" - often used where "lets" works fine

Examples:

• "comprehensive documentation" → "documentation"
• "enables external programs to respond" → "lets external programs respond"

Hedging & Filler

The docs hedge too much. You state facts, not intentions:

• "This document describes..." → just describe it
• "This guide will help you..." → just show how
• "The hook system enables AI agents to participate in chat naturally." → "The hook system lets AI agents respond to chat events."

Passive Voice

Several sections use passive where active is clearer:

• "Events are passed to hooks as JSON" → "Hooks receive events as JSON on stdin"
• "Credentials are stored in..." → "The CLI stores credentials in..."

Over-Explaining

Some sections explain obvious things:

• The README's "Why Chattermax?" section lists features that are already in the Features section
• CONTRIBUTING.md has a lot of preamble before getting to useful info
• "Table of Contents" on every doc is probably overkill for files this size

Missing Your Voice

What's missing is the directness and technical specificity you prefer:

• The architecture doc is good but could name actual functions/modules
• Hook examples are solid but could show real error cases
• The "Current Limitations" section is honest - that's good, more of that

Template Cruft

These files feel templated rather than authored:

• CODE_OF_CONDUCT.md - standard Contributor Covenant, fine as-is
• PR_TEMPLATE.md - the checklist is heavy, could be lighter
• SECURITY.md - reasonable but the "What to Expect" timeline feels optimistic for a side project

Suggestions

1. README.md: Cut the "Why Chattermax?" section. The hook system config example already shows the value prop.

2. CONTRIBUTING.md: This is 373 lines. Could be 100. Most of it is standard Rust dev that contributors already know.

3. getting-started.md: The "Verifying Your Installation" section is good - practical, specific commands. More like that.

4. hooks.md: Best doc in the set. The examples are concrete and useful. The Python AI assistant example is exactly right.

5. architecture.md: Good structure but could use more "here's the specific file where X happens" callouts.

6. CHANGELOG.md: Lists 0.1.0 features but implementation hasn't started? This will cause confusion.

The Big Question

Do you need all these docs right now? The project status says "Specification complete, ready for implementation."

Writing docs before code exists creates:

• Docs that don't match reality
• Maintenance burden before you ship
• Commits that are mostly doc updates

Consider: README + getting-started + hooks.md might be enough for now. Add the rest when you have users asking questions.