Expose submissions: list_submissions, and get_task shows your own

Adds what the API actually permits, which is less than the request asked
for and worth being precise about.

GET /api/v3/submissions/status/task/{taskId} is the only submission
route — no list, no fetch-by-id — so a task id is the only way in. The
probe in the report missed it by trying /api/v3/submissions (404). Its
payload is {id, submitters, isSubmitted, isGraded, grade,
submittingCourseGroupName} and nothing more: no submitted text, no grade
comment, no graded-at. Those lived on /api/v1, which this instance does
not serve at all (404 across the board, confirmed — not the proxy). So
"what feedback did I get" is answerable only when the feedback is a file.

Submitted files are reachable, which covers the main workflow:
get_task now shows the submission id, graded state, grade, group, and
the handed-in files with ids ready for download_file. list_submissions
surveys tasks for "what have I handed in" and "what is still ungraded".
Both state the text/feedback gap rather than implying none was given.

Two things found while building it:

files-storage ignores the parentType path segment when listing —
.../gradings/{id} returns the same records, saying parentType
"submissions". Filtering on each record's own parentType, or a student's
own upload gets reported back as teacher feedback.

get_task could not find this task at all: the task lists only cover the
dashboard, and group-project tasks are absent from both, so it claimed
the id was wrong for a task the account can plainly see. It now falls
back to scanning course pages.

Also bounds live search by measured cost: resolving attachments needs a
request per board element, which is 2s for one course but 325s for all
of them — beyond any client timeout. An unscoped fresh search now reads
text only and says so.

38/38 smoke checks; verified end to end through Claude Code against a
real graded group submission.

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

CLAUDE.md

@@ -123,6 +123,13 @@ 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`.
+- **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
+  feedback means none was given.
+- **files-storage listing ignores the `parentType` path segment** — filter on
+  each record's own `parentType`, or submission files get reported as grading
+  files.
 - **Board file elements carry no file id.** Files are found by listing
   files-storage with `parentType: 'boardnodes'` and the *element* id as
   `parentId`. Same for `fileFolder` and `drawing`.