feat(exim): add iblai-api-exim skill for data export/import

[mamigot]

What

Adds /iblai-api-exim — a new skill covering /api/exim/manage/, which had zero coverage in this repo. Nothing here overlaps an existing skill.

Two independent lanes live under that prefix, and the skill keeps them clearly separated:

• Platform migrations — whole-organization export/import. Start a run, poll status + phase, download the resulting bundle .zip, and upload that same zip to another deployment to import it. This is the "take my data with me" path, and it's the reason this gap was worth closing: it's the API behind data ownership, and an agent couldn't drive it at all.
• Course export/import — per-course publishing to a Studio (CMS) target. Eligibility records, target environments, and the EximTask queue (read-only, plus cancel).

Why this was missing

It never surfaced because it isn't in the developer docs either — it's an API-only surface. It came out of a coverage sweep comparing this repo against the platform's full route inventory.

Sourcing

Per CLAUDE.md ("source of truth = the repo URLconf, not the docs"), every endpoint, request field, permission, and status code was read off iblai-dm-pro — ibl-dm-import-export-manager/{urls.py,views.py,serializers.py} and platform_migration/components.py — not from the published OpenAPI schema, which carries no request/response bodies for these routes.

That sourcing produced details the schema alone could not have:

• IsDMAdmin on every endpoint
• the 503 feature gate on both start paths
• the 409 cancel race (conditional UPDATE — only a pending run/task can be canceled; an executing run is never interrupted)
• download's 400 / 409 / 404 conditions and its 302 to a presigned S3 URL on multi-node deployments
• token being write-only on target environments
• the "either oauth_credentials or token" validation rule
• the exact multipart fields on import-upload/, and that source_key is read from the bundle, not the request
• the full component registry with mandatory vs optional sets

Structure

Follows the canonical section order from CLAUDE.md: Auth & conventions → Concepts → Reads → Writes → Example → Notes → Reference material, with resource groupings as ### inside Reads/Writes. Every destructive or outward-facing call is marked "confirm with the user first."

references/platform-migration.md holds what would bloat the primary: the run lifecycle, the component registry table (which data sets are mandatory vs optional and what each carries), status/phase semantics, and the deployment-to-deployment bundle handoff including where the bundle physically lives on single-node vs S3 deployments.

Also

• README: skills badge 47 → 48, added to the Organization group and the skill table.

Worth a reviewer's eye

• The Component registry table is transcribed from components.py. If that registry has changed since, the table needs the same edit.
• I documented direction: "import" with a bundle_path as the alternative to import-upload/. That path is inferred from the serializer's validation rules rather than from an explicit code path — worth confirming it's a supported flow and not just a permissive validator.

🤖 Generated with Claude Code