Set up milestones + area/blocker labels as the source of truth

[CodeSculptor]

Context

The release-process review recommended GitHub Issues + milestones become the source of truth for release scope (rather than release notes + session memory). Labels are partially there (upstream-sync, conflict, bug, enhancement) but milestones and the granular area: / *-blocker labels are missing.

Milestones to create

• v0.4 Beta Reset
• v0.5 Feature Parity Audit
• v0.6 Layout/Orientation
• v0.7 Player Polish
• v1.0 Release Candidate

Labels to add

Area: area: upstream-sync, area: phone-ui, area: tablet-ui, area: player, area: channel, area: comments, area: account, area: notifications, area: settings, area: updates

Type/severity: type: regression, type: missing-feature, type: chore, release-blocker, beta-blocker, stable-blocker

(bug / enhancement already exist and can map to type:bug / type:missing-feature.)

Acceptance criteria

• Milestones created and existing open issues assigned where they fit
• Area + blocker labels created
• Existing open issues (Casting / Chromecast not available in the phone UI #7, F-Droid listing #9, Tracking: upstream features not yet exposed in the phone UI #11, Intermittent UnknownHostException (sign-in / network) on some devices #13, [BUG]: show UI on next video, auto hide UI - Never #14) re-labelled with area + severity
• RELEASE_PROCESS.md notes "every task starts from an issue, ends with the issue updated"

Notes

Single-maintainer repo, so full Scrum ceremony is overkill — but milestones + blocker labels are the minimum to stop release scope living only in memory.

[CodeSculptor]

Deferring for now, alongside #19.

Milestones + granular area: / *-blocker labels are worth having, but the current model keeps release scope in docs/KNOWN_ISSUES.md + docs/FEATURE_MATRIX.md + the roadmap, reconciled against open Issues at each release (see release_known_issues_on_github practice). That's sufficient at the current single-maintainer scale. Revisit together with the branch-model decision in #19.