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>

docs/API.md

@@ -119,6 +119,23 @@ parser underneath them. Verified live — 20 ids return 200, 21 return 400 with
 identical ids. A board with more than 20 cards is therefore unreadable in one
 request; `getCards` chunks at 20.
 
+**Submissions are nearly invisible.** The only route is
+`GET /api/v3/submissions/status/task/{taskId}` — there is no `GET /submissions`
+and no fetch-by-id, so a task id is the only way to reach a submission. The
+response carries `{id, submitters, isSubmitted, isGraded, grade,
+submittingCourseGroupName}` and **nothing else**: no submitted text, no grade
+comment, no graded-at. Those lived on the legacy Feathers API, and `/api/v1` is
+not served on this instance (404 across the board), so they are simply
+unavailable. Submitted *files* are reachable through files-storage with
+`parentType: 'submissions'`.
+
+**files-storage ignores `parentType` when listing.** Asking for
+`.../gradings/{submissionId}` returns the files parented to that id whatever
+their type — the records come back saying `parentType: "submissions"`. The path
+segment appears to serve authorisation, not filtering, so filter on each
+record's own `parentType` or a student's own upload will be reported back as
+teacher feedback.
+
 **`storageLocationId` is the school id** (from `/me`), with
 `storageLocation: 'school'`, for every parent type in normal use.