feat: v1.2.0-rc.1 - IndieWeb Features Release Candidate

Complete implementation of v1.2.0 "IndieWeb Features" release.

## Phase 1: Custom Slugs
- Optional custom slug field in note creation form
- Auto-sanitization (lowercase, hyphens only)
- Uniqueness validation with auto-numbering
- Read-only after creation to preserve permalinks
- Matches Micropub mp-slug behavior

## Phase 2: Author Discovery + Microformats2
- Automatic h-card discovery from IndieAuth identity URL
- 24-hour caching with graceful fallback
- Never blocks login (per ADR-061)
- Complete h-entry, h-card, h-feed markup
- All required Microformats2 properties
- rel-me links for identity verification
- Passes IndieWeb validation

## Phase 3: Media Upload
- Upload up to 4 images per note (JPEG, PNG, GIF, WebP)
- Automatic optimization with Pillow
  - Auto-resize to 2048px
  - EXIF orientation correction
  - 95% quality compression
- Social media-style layout (media top, text below)
- Optional captions for accessibility
- Integration with all feed formats (RSS, ATOM, JSON Feed)
- Date-organized storage with UUID filenames
- Immutable caching (1 year)

## Database Changes
- migrations/006_add_author_profile.sql - Author discovery cache
- migrations/007_add_media_support.sql - Media storage

## New Modules
- starpunk/author_discovery.py - h-card discovery and caching
- starpunk/media.py - Image upload, validation, optimization

## Documentation
- 4 new ADRs (056, 057, 058, 061)
- Complete design specifications
- Developer Q&A with 40+ questions answered
- 3 implementation reports
- 3 architect reviews (all approved)

## Testing
- 56 new tests for v1.2.0 features
- 842 total tests in suite
- All v1.2.0 feature tests passing

## Dependencies
- Added: mf2py (Microformats2 parser)
- Added: Pillow (image processing)

Version: 1.2.0-rc.1

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

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

docs/decisions/ADR-056-no-selfhosted-indieauth.md

@@ -0,0 +1,110 @@
+# ADR-056: Use External IndieAuth Provider (Never Self-Host)
+
+## Status
+**ACCEPTED** - This is a permanent, non-negotiable decision.
+
+## Context
+StarPunk is a minimal IndieWeb CMS focused on **content creation and syndication**, not identity infrastructure. The project philosophy demands that every line of code must justify its existence.
+
+The question of whether to implement self-hosted IndieAuth has been raised multiple times. This ADR documents the final, permanent decision on this matter.
+
+## Decision
+**StarPunk will NEVER implement self-hosted IndieAuth.**
+
+We will always rely on external IndieAuth providers such as:
+- indielogin.com (primary recommendation)
+- Other established IndieAuth providers
+
+This decision is **permanent and non-negotiable**.
+
+## Rationale
+
+### 1. Project Focus
+StarPunk's mission is to be a minimal CMS for publishing IndieWeb content. Our core competencies are:
+- Publishing notes with proper microformats
+- Generating RSS/Atom/JSON feeds
+- Implementing Micropub for content creation
+- Media management for content
+
+Identity infrastructure is explicitly **NOT** our focus.
+
+### 2. Complexity vs Value
+Implementing IndieAuth would require:
+- OAuth 2.0 implementation
+- Token management
+- Security considerations
+- Key storage and rotation
+- User profile management
+- Authorization code flows
+
+This represents hundreds or thousands of lines of code that don't serve our core mission of content publishing.
+
+### 3. Existing Solutions Work
+External IndieAuth providers like indielogin.com:
+- Are battle-tested
+- Handle security updates
+- Support multiple authentication methods
+- Are free to use
+- Align with IndieWeb principles of building on existing infrastructure
+
+### 4. Philosophy Alignment
+Our core philosophy states: "Every line of code must justify its existence. When in doubt, leave it out."
+
+Self-hosted IndieAuth cannot justify its existence in a minimal content-focused CMS.
+
+## Consequences
+
+### Positive
+- Dramatically reduced codebase complexity
+- No security burden for identity management
+- Faster development of content features
+- Clear project boundaries
+- User authentication "just works" via proven providers
+
+### Negative
+- Dependency on external service (indielogin.com)
+- Cannot function without internet connection to auth provider
+- No control over authentication user experience
+
+### Mitigations
+- Document clear setup instructions for using indielogin.com
+- Support multiple external providers for redundancy
+- Cache authentication tokens appropriately
+
+## Alternatives Considered
+
+### 1. Self-Hosted IndieAuth (REJECTED)
+**Why considered:** Full control over authentication
+**Why rejected:** Massive scope creep, violates project philosophy
+
+### 2. No Authentication (REJECTED)
+**Why considered:** Ultimate simplicity
+**Why rejected:** Single-user system still needs access control
+
+### 3. Basic Auth or Simple Password (REJECTED)
+**Why considered:** Very simple to implement
+**Why rejected:** Not IndieWeb compliant, poor user experience
+
+### 4. Hybrid Approach (REJECTED)
+**Why considered:** Optional self-hosted with external fallback
+**Why rejected:** Maintains complexity we're trying to avoid
+
+## Implementation Notes
+
+All authentication code should:
+1. Assume an external IndieAuth provider
+2. Never include hooks or abstractions for self-hosting
+3. Document indielogin.com as the recommended provider
+4. Include clear error messages when auth provider is unavailable
+
+## References
+- Project Philosophy: "Every line of code must justify its existence"
+- IndieAuth Specification: https://indieauth.spec.indieweb.org/
+- indielogin.com: https://indielogin.com/
+
+## Final Note
+This decision has been made after extensive consideration and multiple discussions. It is final.
+
+**Do not propose self-hosted IndieAuth in future architectural discussions.**
+
+The goal of StarPunk is **content**, not **identity**.