[QTI] Backend handling, validation, and publishing of assessment items from frontend and ricecooker

[rtibbles]

Overview

The new QTI editor (#5970) emits one complete <qti-assessment-item> XML document per item, stored in AssessmentItem.raw_data with type='QTI'. This issue tracks the backend that stores those items, validates QTI from every source, publishes them as QTI packages (dual-publishing Perseus where the interaction type allows), and accepts QTI uploaded through the internal/ricecooker API.

Scope

In:

• Persisting authored QTI XML and round-tripping it through sync + internal API
• Authoritative QTI 3.0 schema (XSD) validation for all sources
• Publishing native QTI items as QTI/IMSCP packages
• Dual-publishing Perseus for QTI items whose interaction type Perseus can express
• Accepting arbitrary QTI via ricecooker upload
• Publishing mixed Perseus + QTI exercises as one package
• Migrating legacy studio-authored items to QTI

Out:

• The frontend editor and editability detection ([QTI] Build and ship the new QTI editor for core interaction types #5970 and children)
• Extending the pydantic QTI models to the full spec (see Strategy)
• QTI viewer / learner preview

Strategy

• type is always QTI; raw_data holds one complete <qti-assessment-item> XML string, atomic under field-level sync.
• Authoritative compliance validation is schema-based (QTI 3.0 XSD) and runs for every source.
• The pydantic models (contentcuration/utils/assessment/qti/, [QTI] Build the QTI declaration model with XML parsing and serialization #5965) stay a restricted subset: used only to generate QTI from non-QTI structured data and to read the choice/text-entry subset for Perseus derivation. They are not extended to the full spec.
• Editability is a frontend round-trip concern. Arbitrary QTI from ricecooker is non-editable and published verbatim.

AI usage

Architecture decided with the maintainer across an iterative session: blanket QTI type with the item XML in raw_data; XSD-authoritative validation across all sources; a legacy→QTI global migration with an API-layer dual-read; ricecooker upload delegating to the AssessmentItem serializer; and a Perseus custom-interaction contract confirmed against the QTI 3.0 specification. Claude mapped the existing publish/validation/ricecooker code, proposed the breakdown, and drafted each issue; the maintainer steered every decision and reviewed throughout.