Board JSON import has no entity-count caps (large payloads, heavy single transaction)

[Chris0Jeky]

See coordinator findings S-ImportCaps. ImportBoardCoreAsync validates the whole payload transactionally (good) but enforces no caps on column/card/label counts; the only bound is Kestrel MaxRequestBodySize (~30MB), which admits tens of thousands of cards in one request/transaction (authenticated self-serve DoS on shared DB/CPU). Assignee mappings are correctly restricted to self-or-unassigned. Suggested: cap columns/cards/labels/relations per import (with a clear 400/413 message), consistent with round-trip needs for legitimately large boards.

[Chris0Jeky]

Consumer note: GetByIdWithDetailsAsync loads the full board (columns+cards+labels, split-query so no cartesian explosion, but unbounded row count) for the board-detail endpoint. Import caps bound the supply side; column-level pagination on the detail read remains a separate, larger decision if giant boards are otherwise reachable.

[Chris0Jeky]

Same-theme note: starter-pack manifests also have no entity-count cap (schema validator checks shape only; apply creates all planned columns/cards/labels, bounded by body size alone). Consider sharing the bulk-create cap with board JSON import.

[Chris0Jeky]

Same-theme note: external CSV import caps payload bytes (MaxCsvPayloadBytes) but not row/card count — a dense small-row CSV can still yield tens of thousands of cards. Include a row cap in the same bulk-create work.