Reach tasks attached to topics, and read Etherpad pads

Testing against a local instance turned up four things the server was
getting wrong, all of them invisible against the live account because the
data that exposes them had never been produced there.

`GET /lessons/{id}/tasks` returns a bare array, not the `{data,total}`
envelope every sibling endpoint uses, so `.data` was undefined and a
topic's tasks silently vanished. Its items also carry no id at all —
`LessonLinkedTaskResponse` has no id property — which leaves a
topic-attached task unidentifiable: it is not a task element on the
course page, and once past due it is in neither task list. So its
submission, and its grade, could not be reached by any route. That is 18
of 60 tasks on the real account, now reachable: the ids come off the
legacy topic page, where each task is linked as `/homework/{id}`.

The types said `id: string` and `status: TaskStatus` on something that
has neither, which is what let this stay quiet; `LessonLinkedTask` and
`ResolvedTask` now say what is actually there.

Collaborative text editor elements come back with `content: {}`, and the
tool said their contents were unavailable. They are available: the
content-element endpoint returns the pad url *and* an Etherpad session
cookie, and the pad exports itself as text to whoever holds it. No API
key needed. Pads are now shown by get_board and indexed for search.

The store's file digest covered id and size on the grounds that file
records are immutable. `PATCH /file/rename/{id}` renames one in place,
so a rename was reported as nothing at all.

Finally, get_board reported an unpublished board as "no permission",
which sends the reader hunting for an access problem that is not there.

smoke gains checks for topic tasks and for pads, and no longer assumes a
populated index or a search term that happens to match. 39/39 live-only
and 41/41 index-backed, against both the live instance and a local one.

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

CLAUDE.md

@@ -123,6 +123,20 @@ These cost real time to discover; `docs/API.md` has the full list with evidence.
 - **Never swallow a per-item crawl error.** Board failures used to be caught and
   dropped, so the index lost whole boards while the crawl reported success —
   which is how the 20-id limit went unnoticed. They go into `Snapshot.failures`.
+- **`GET /lessons/{id}/tasks` is a bare array whose items carry no id.** Not the
+  `{data,total}` envelope, and `LessonLinkedTaskResponse` has no id field at
+  all. A topic-attached task is thus unidentifiable from the API and invisible
+  in both task lists once past due — 18 of 60 tasks on the real account.
+  `core/lesson-page.ts` scrapes the ids off the legacy topic page.
+- **Collaborative text editor (Etherpad) contents are reachable, in two hops.**
+  `GET /api/v3/collaborative-text-editor/content-element/{id}` returns the pad
+  url *and* sets an Etherpad `sessionID` cookie; `/etherpad/p/{id}/export/txt`
+  then returns the text. No Etherpad API key needed. `core/etherpad.ts` checks
+  the url's host before sending the cookie to it.
+- **A draft board is listed on the course page but 403s when opened.** Say "not
+  published yet", not "no access".
+- **File records are mutable**: `PATCH /file/rename/{id}` keeps the id and size,
+  so the store's digest has to include the name.
 - **Submissions: only `GET /submissions/status/task/{taskId}` exists.** No list,
   no fetch-by-id, and the payload has no submitted text, grade comment or
   graded-at — `/api/v1`, which had them, is not served here. Don't imply absent