tasks: CalDAV provider (Nextcloud Tasks/iOS), review reports unknown values; bump stops pointing at release (#139)

Files changed:
- CHANGES.md
- INSTALL.md
- VERSION
- instructions/dev/version-parts.md
- instructions/gtd-weekly-review/SKILL.md
- tools/CONTRACT.md
- tools/chemenu/commands/doctor.py
- tools/chemenu/commands/version_cmd.py
- tools/chemenu/review.py
- tools/chemenu/tasks/__init__.py
- tools/chemenu/tasks/caldav.py
- tools/chemenu/tasks/config.py
- tools/chemenu/tests/test_caldav.py
- tools/chemenu/tests/test_doctor.py
- tools/chemenu/tests/test_review.py
- tools/requirements.txt

instructions/dev/version-parts.md

@@ -198,7 +198,12 @@ the three-line test below is usually enough.
    never reported by anything. The 5.0.0 candidate is the case: it declared `--no-migration` for
    a TOC-verification change, then absorbed a schema removal that migrates 152 pages.
 
-7. **Review the graded list before fixing the candidate, and regrade what reads wrong.** Run
+7. **Fix the candidate only when the user asks for a release.** Whether a candidate ships is the
+   user's call, never a session's: a work package being finished is not a reason, since the
+   candidate model exists precisely so that one does not become one release. A session that
+   bumps stops at the open `-beta.N` candidate; the next `publish` then carries it without
+   triggering `release.yml`. Once the user does ask, review the graded list first, and regrade
+   what reads wrong. Run
    `tools/wikitool version regrade` with no arguments - it lists every bump at its current grade,
    numbered in rendered order. A candidate that grew over several sessions often has a bump graded
    in isolation that reads differently once the whole shape is visible; `version regrade 3 7

instructions/gtd-weekly-review/SKILL.md

@@ -59,6 +59,8 @@ surface, lives in `docs/knowledge-and-commitment.md`, which this skill does not
    | `unpaged_project` | A tracker project has no `kb/` page, past the age threshold | (a) It has grown a memory worth keeping (participants, decisions, context) - `tools/wikitool new project --name "<Name>" --set responsibility=<area>`. (b) It genuinely never needs one - confirm and leave it tracker-only | Ask: would anyone, including the operator in six months, need to know *why* this exists or who is in it? If yes, (a); a project that is fully explained by its own title and task list stays (b) |
    | `no_open_loop` | A `kb/` page is `state: active` but its tracker project is missing or empty | (a) Same three options as `stalled` above. (b) The name diverged - a rename happened on one side only | Before assuming a stall, check whether a *similarly* named tracker project exists. If it does, this is `instructions/page-lifecycle.md`'s rename case (`tools/wikitool rename` for the page, plus renaming the tracker project to match), not a state change - the review reports both directions of a rename so it never has to be inferred silently |
    | `someday_stale` | A someday/maybe item has not been touched past the threshold | (a) Activate it - give it a page with `tools/wikitool new project` if it is ready to become a committed initiative. (b) Strike it - propose `tools/wikitool task close --id "<id>"` (the finding's own `item_id`), asked as one combined question naming the item's title and id, then run it once confirmed. (c) Leave it - still genuinely "maybe" | Would the user commit to starting this today? If yes, (a). If it no longer belongs on the list at all, (b). If it is still worth keeping but not yet, (c) is a legitimate answer, not inaction - do not force a decision the user is not ready to make |
+   | `waiting_no_follow_up` | A `WAITING` item carries no `follow_up_at` at all - the provider had nothing to judge staleness against, so `waiting_overdue` could not even ask the question | (a) Set a follow-up date on the item, in the tracker itself - there is no `wikitool` command for this, same as moving a reminder forward. (b) Leave it open-ended deliberately - some commitments genuinely have no date yet | Ask whether there is a date to follow up on at all. If yes, (a); if the item is a genuine "whenever they get back to me", (b) is legitimate, but say so plainly rather than treating the finding as resolved by itself |
+   | `project_age_unknown` | A tracker project has no determinable creation date - the provider could not supply one (an empty project, or a server that never reports it), so `unpaged_project` could not judge its age either way | (a) Judge it on its own merits regardless of age - if it clearly deserves a `kb/` page now, `tools/wikitool new project --name "<Name>" --set responsibility=<area>`. (b) Leave it - it becomes ordinary `unpaged_project` material once it does gain a determinable age | There is no date to reason from here, unlike `unpaged_project` - ask the same "would anyone need to know why this exists" question from that row, but without an age argument on either side |
 
 3. **Record what was decided or learned on the page - never the task list.** A decision made this
    week (a scope cut, a direction change) goes under `## Entscheidungen`; something that showed