feat(write): event delete + WRITE_CALENDAR foundation (v1.1)

First slice of milestone 2 (write support), per the new plan in
docs/superpowers/plans/2026-06-11-03-write-support.md:

- Delete from the event detail screen with confirmation; recurring events
  choose "only this event" (cancelled exception via CONTENT_EXCEPTION_URI,
  series survives) or "all events in the series" (Events-row delete)
- WRITE_CALENDAR in the manifest; onboarding requests read+write in one
  system dialog but only read gates the app — declining write keeps it
  usable read-only. v1.0 installs get a contextual write request on their
  first delete
- CALENDAR_ACCESS_LEVEL is read into CalendarSource.canModifyContents;
  read-only calendars (WebCal, birthdays, …) show no write actions. The
  no-op placeholder Edit button is removed until edit ships (v1.3)
- Onboarding copy drops the now-false "read-only" claim (DE+EN)
- Tests: repository delete delegation/error propagation, access-level
  mapping; FakeCalendarDataSource grows write ops

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

.planning/ROADMAP.md

@@ -53,11 +53,18 @@ after v0.6 (full event read) plus the onboarding-screen polish pass.
 - ~~Redesign the initial grant-access (permission) screen~~ — **done**
   (Material 3 Expressive onboarding, shipped in v0.6.0 / v1.0.0)
 
-## v2.0 — Write Support
+## v2.0 — Write Support (in progress)
 
-- Event create / edit / delete via `CalendarContract` writes
-- Quick-add sheet
-- Conflict UX (event modified externally during edit)
+Delivered in four releasable slices (plan:
+`docs/superpowers/plans/2026-06-11-03-write-support.md`). The V1 spec is a
+guide here, not a contract — scope per slice is decided as we go.
+
+| Version | Milestone | Status |
+|---|---|---|
+| v1.1 | Write foundation — `WRITE_CALENDAR`, read-only-calendar detection, delete (series + single occurrence) | in progress |
+| v1.2 | Create event — form, FAB, default-calendar pref | planned |
+| v1.3 | Edit event — shared form, series edit, reminders, simple recurrence picker | planned |
+| v2.0 | Quick-add, occurrence edit, conflict dialog, polish, release | planned |
 
 ## v3.0 — Power-User Features
 

.planning/STATE.md

@@ -4,10 +4,10 @@
 
 ## Status
 
-**Milestone:** v1.0.0 — First public release (shipped 2026-06-11)
-**Phase:** V1 is complete and released. All screens done, the read model
-surfaces every readable `CalendarContract` field, and the onboarding screen
-got its Material 3 Expressive polish pass. Next horizon is v2.0 (write support)
+**Milestone:** v2.0 — Write support (milestone 2, in progress)
+**Phase:** v1.0.0 shipped 2026-06-11. Milestone 2 is planned in four slices
+(`docs/superpowers/plans/2026-06-11-03-write-support.md`); slice v1.1
+(write foundation + delete) is implemented and awaiting release.
 
 ## Progress
 
@@ -28,7 +28,15 @@ got its Material 3 Expressive polish pass. Next horizon is v2.0 (write support)
   URLs in the detail view; new domain enums + mapper unit tests. (A dedicated
   URL field was cut — no `CalendarContract` column backs it.)
 
+- [x] v1.1 write foundation — `WRITE_CALENDAR` (onboarding asks READ+WRITE,
+  only READ gates; contextual upgrade for v1.0 installs), read-only-calendar
+  detection (`CALENDAR_ACCESS_LEVEL` → `canModifyContents`, actions hidden for
+  WebCal/birthday calendars), delete from the detail screen (recurring:
+  "only this event" via cancelled exception / "all events in the series"),
+  repository + mapper tests
+
 ## Next
 
-1. v1.0.0 released — monitor the F-Droid build/publish
-2. Plan v2.0 (write support: create / edit / delete, quick-add, conflict UX)
+1. Cut v1.1 release (changelog entry is staged under [Unreleased])
+2. v1.2 — create event: form screen, FAB, default-calendar pref, `insertEvent`
+3. v1.0.0 — keep monitoring the F-Droid build/publish