local-instance: simulate a teacher, and run the files-storage consumer

`scripts/simulate-teacher.mjs` creates, edits and deletes what teachers
create — course, room, topic, task, board, columns, cards, rich text,
link, Etherpad pad, folder, files — so the MCP server can be exercised
against content the real account has never held. It is the only thing
here that writes to a Schulcloud and refuses any non-localhost address.
`scripts/mcp-env.sh` points the server and CLI at the instance.

Two gaps it exposed in the stack itself:

The files-storage AMQP consumer is a separate entrypoint, and we were
running only the HTTP one. Nothing was bound to the `files-storage`
exchange, so `TaskService.delete` — which awaits deleteFilesOfParent
over AMQP before touching the task — hung until the request timeout.
Deleting any task or topic answered 408 with the entity still there.

The demo data is dated 2017-2018 and the v3 endpoints filter on those
dates, so a student saw no tasks at all. seed.sh now brings courses and
homework into the present, which is the difference between a fixture
that exercises the student-facing surface and one that looks empty.

Teams turn out to be uncreatable through the API (the legacy service
registers no `create`, v3 has no route), and a new board is unpublished
and 403s for students, so the simulation adopts a seeded team and leaves
one board a draft on purpose.

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

local-instance/env/api.env

@@ -93,3 +93,8 @@ FEATURE_VIDIS_MEDIA_ACTIVATIONS_ENABLED=false
 # is off, so they get a placeholder rather than a real service. Hydra is the
 # OAuth2 provider behind external tool launches; we do not run it.
 HYDRA_URI=http://hydra.invalid:4444
+
+# Calendar. The live deployment runs a schulcloud-calendar service and this
+# stack does not. Deletions still succeed: the calendar call fails and is
+# tolerated. Nothing here reads calendars.
+CALENDAR_SERVICE_ENABLED=false