Document calendar target switch to calendar.family_2

Two HA entities are both named "Family" (calendar.family and
calendar.family_2); the automation now targets _2 per user preference.
Note it only supports create_event, not delete, so a bad push has to be
cleaned up manually in Google Calendar rather than via the HA API.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KsJqAZ82Veyf5oihBr71S5

CLAUDE.md

@@ -25,16 +25,22 @@ Runs as one Docker container on the user's Unraid home server.
   `{"date": ..., "items": [...]}` to that webhook, independent of whether
   the SMS send itself succeeds. On the HA side (`automation.lunch_menu_family_calendar`,
   `http://192.168.86.207:8123`), a `local_only` webhook trigger runs
-  `calendar.create_event` against `calendar.family`, producing an all-day
-  event with the menu as the description (bulleted). This makes the
-  scrape here the single source of truth — HA doesn't poll or re-scrape
-  anything. The webhook id is a random token that lives only in the
-  server's `.env` (`HA_WEBHOOK_URL`) and in the automation's trigger
-  config — never committed here. If the calendar push stops working,
-  check both ends: `GET /api/integrations` on this app reports whether
-  `HA_WEBHOOK_URL` is set at all, and `ha_get_automation_traces` on
-  `automation.lunch_menu_family_calendar` shows whether HA is even
-  receiving the webhook.
+  `calendar.create_event` against `calendar.family_2` (the "Family" Google
+  Calendar entity — there are two entities both named "Family" in this HA
+  instance, `calendar.family` and `calendar.family_2`; this integration
+  deliberately targets `_2`), producing an all-day event with the menu as
+  the description (bulleted). This makes the scrape here the single
+  source of truth — HA doesn't poll or re-scrape anything.
+  `calendar.family_2` only supports `create_event`, not `delete_event` —
+  a bad push can't be cleaned up via the HA API, only manually in Google
+  Calendar. No duplicate-prevention either way: re-pushing the same
+  date's menu creates a second event. The webhook id is a random token
+  that lives only in the server's `.env` (`HA_WEBHOOK_URL`) and in the
+  automation's trigger config — never committed here. If the calendar
+  push stops working, check both ends: `GET /api/integrations` on this
+  app reports whether `HA_WEBHOOK_URL` is set at all, and
+  `ha_get_automation_traces` on `automation.lunch_menu_family_calendar`
+  shows whether HA is even receiving the webhook.
 - **Manual actions (2026-09-03):** besides "Send Lunch Menu Now" (full job —
   scrape, HA push, text everyone), the UI has "Push to Calendar Only"
   (`POST /api/push-calendar` → `push_calendar_only()`, scrape + HA push, no