[QTI] A QTI item containing an XML comment fails the channel publish

[rtibblesbot]

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Target branch: unstable

Observed behavior

• A native qti item whose XML contains a comment passes validate_qti_item.
• is_perseus_derivable then raises ValueError on it. _node_is_perseus_derivable calls it from publish.py with no try.
• _local in utils/assessment/qti/perseus_derive.py passes every node from .iter() to etree.QName, and a comment node has no tag name.
• derive_perseus_item raises the same error through _interaction_elements.

Errors and logs

>>> xml = VALID_CHOICE_ITEM.replace("<qti-item-body>", "<qti-item-body><!-- note -->", 1)
>>> validate_qti_item(xml.encode()).is_valid
True
>>> is_perseus_derivable(xml)
ValueError: Invalid input tag of type <class '_cython_3_2_4.cython_function_or_method'>

User-facing consequences

A single item uploaded through ricecooker or written through the sync API, with a comment anywhere in its XML, blocks publishing the whole channel.

Steps to reproduce

1. Store VALID_CHOICE_ITEM (tests/utils/qti/test_validation.py) with <!-- note --> inserted after <qti-item-body> as the raw_data of a qti AssessmentItem on an exercise.
2. Publish the channel.

Acceptance Criteria

• An exercise whose only item is a derivable choice item containing XML comments publishes both the QTI package and the derived Perseus archive.
• Comments and processing instructions in an item change neither the derivability result nor the derived Perseus content.
• A test publishes a commented item and checks both archives.

AI usage

I used Claude Code to review the #6189 branch. It reproduced this on upstream/unstable with is_perseus_derivable and a generator-level publish, and drafted this issue. The step from there to the channel publish failing comes from reading publish.py.

[rtibblesbot]

Plan: A native QTI item containing XML comments or processing instructions derives (and publishes) exactly as it would without them.

• Ignore comments and processing instructions when deriving
• Publish test for a commented item
• Self-review the produced code

Assumptions — the issue did not settle these; say so if one is wrong.

• Strip comments/PIs in _parse rather than harden html_to_markdown; if wrong, html_to_markdown called elsewhere with comment-bearing elements would still raise in _list_lines/_render_math (today only perseus_derive calls it).
• Publish test asserts the QTI zip keeps the comment verbatim; if the team wants comments stripped from the QTI package, that assertion and archive.py change.
• lxml is absent from the planning sandbox, so strip_tags tail-merge is taken from lxml docs; the Task 1 tests verify it.

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

• Implemented code following the pre-approved plan using test-driven development (red-green-refactor)
• Ran the project's full test suite and linter before committing
• For UI changes: captured live screenshots to verify rendering
• For backend changes: verified with example API/CLI output