Add comprehensive technical decisions to PRDs documenting architecture
choices for community handles and moderator record storage.

PRD_COMMUNITIES.md:
- Add technical decision: Single handle field (2025-10-11)
- Update lexicon summary to reflect DNS-valid handle approach
- Add DNS infrastructure checklist items (wildcard setup, well-known endpoint)
- Document that !name@instance format is client-side display only

PRD_GOVERNANCE.md:
- Add technical decision: Moderator records storage location (2025-10-11)
- Document security analysis comparing user repo vs community repo
- Explain attack vector for malicious self-hosted instances
- Rationale: Community repo provides better security and federation

Key decisions documented:
1. Single handle field matches Bluesky pattern (app.bsky.actor.profile)
2. Separation of concerns: protocol (DNS handle) vs presentation (!prefix)
3. Moderator records in community repo prevents forgery attacks
4. DNS wildcard required for *.communities.coves.social resolution

Infrastructure requirements added:
- [ ] DNS Wildcard Setup: Configure *.communities.coves.social
- [ ] Well-Known Endpoint: Implement .well-known/atproto-did handler

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Update all community tests to use DNS-valid atProto handles instead of
scoped handle format. All tests passing including E2E, integration, and
unit test suites.

Changes:
- Update test fixtures to use DNS-valid handles
- Remove atprotoHandle references from test data
- Rename TestCommunityConsumer_AtprotoHandleField to TestCommunityConsumer_HandleField
- Update test assertions to expect DNS format handles
- Fix unused variable warnings in unit tests

Test coverage:
✅ E2E tests (5.57s) - Full PDS → Jetstream → AppView flow
✅ Integration tests (4.36s) - 13 suites covering CRUD, credentials, V2 validation
✅ Unit tests (0.37s) - Service layer, timeout handling, credentials
✅ Lexicon validation (0.40s) - All 60 schemas validated

Example test data changes:
- Before: handle="!gaming@coves.social"
- After: handle="gaming.communities.coves.social"

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Update community service and consumer to work with single handle field.
Remove scoped handle generation (!name@instance) and store DNS-valid
atProto handle directly.

Changes:
- Remove scoped handle generation logic
- Update handle validation regex to accept DNS format
- Store pdsAccount.Handle directly (e.g., gaming.communities.coves.social)
- Consumer uses handle field directly from profile record
- Update comments to reflect single handle approach

Technical details:
- Regex now validates standard DNS hostname format (RFC 1035)
- Allows subdomain format: name.communities.instance.com
- Client UI will derive !name@instance display from name + instance

Impact:
- All E2E tests passing with real PDS and Jetstream
- Handle resolution works correctly
- Community creation/update flows validated

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Remove redundant atprotoHandle field in favor of single DNS-resolvable
handle field. This matches Bluesky's pattern (app.bsky.actor.profile)
and follows atProto best practices.

Changes:
- Remove atprotoHandle field from social.coves.community.profile
- Update handle field description to indicate DNS-resolvable format
- Add format: "handle" validation
- Update test data to use DNS-valid handles

Rationale:
- Single source of truth for community handle
- Reduces confusion about which handle is "real"
- Client-side UI derives display format (!name@instance) from name + instance
- Follows separation of concerns: protocol vs presentation layer

Example:
- Before: handle="!gaming@coves.social", atprotoHandle="gaming.communities.coves.social"
- After: handle="gaming.communities.coves.social", display derived client-side

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Updated PDS_SERVICE_HANDLE_DOMAINS in .env.dev to include both:
- .local.coves.dev (for user accounts)
- .communities.coves.social (for V2 community accounts)

This allows E2E tests to successfully create community PDS accounts with
the proper subdomain. Required for V2 Communities architecture where each
community owns its own PDS account and repository.

Also added PRD_GOVERNANCE.md documenting governance mechanisms.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Minor documentation updates to main.go initialization code
to reflect V2 architecture and current implementation status.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>