test: cover malformed citation edge-case warning branches (#827)

[planetf1]

Summary

The Granite 3.2 and 3.3 citation parsers have ~15 logging.WARNING branches that fire when a model emits malformed output — unclosed <co> tags, non-numeric citation IDs, duplicate citation IDs in the same response, nested control tokens. Every one of those branches was a silent continue with no test coverage; a regression there would ship unnoticed, and real models do emit malformed <co> blocks in production.

This PR extends test_granite32_output.py (+127 lines) and test_granite33_output.py (+25 lines) with targeted warning-branch tests. Each test drives a module-private helper directly with adversarial input, asserts the expected logging.WARNING is emitted via caplog, and asserts the function returns the documented safe default rather than crashing. No production code is changed.

Coverage delta: granite32 78.4% → 83.5%, granite33 83.1% → 84.2%.

Branches covered

Function	Trigger	File
_parse_citations_text	no <co> tags in input	g32
_parse_citations_text	inner Document regex misses	g32
_parse_citations_text	embedded \nDocument N in citation text	g32
_get_docs_from_citations	non-numeric doc_id	g32
_get_docs_from_citations	non-numeric citation_id	g32
_add_citation_response_spans	citation ID absent from response	g32
_add_citation_response_spans	citation at position 0 of first sentence	g32
_add_citation_response_spans	duplicate citation ID across two sentences	g32
_parse_citations_text	no N: numeric pattern	g33
_validate_response	nested CITE_START	g33
_validate_response	tag count ≠ citation_info length	g33
_get_docs_from_citations	non-numeric doc_id	g33

Test plan

• uv run pytest test/formatters/granite/test_granite32_output.py test/formatters/granite/test_granite33_output.py -v — 70 passed, 0 failed
• uv run pytest test/formatters/granite/ -m "not qualitative and not slow" — all 216 pass, no regressions
• All new tests run in <6 s; no backend, Ollama, or qualitative markers needed

Where this fits

Part of epic #726 (testing strategy overhaul), sub-issue #827. PR #818 added the baseline ~200 unit tests; this is PR A of a two-part #827 workstream (edge-case warning branches). PR B — granite-common base/types.py port + answer_relevance_* fixtures — is deferred to a follow-up per the split endorsed in the issue.

Kept as draft pending resolution of discussion #1166 — Does Granite 4.x need its own formatter, or does it use Granite33InputProcessor/Granite33OutputProcessor?. The tests here are correct regardless of the outcome, but the answer may inform whether a granite4 formatter (and corresponding tests) should be bundled with PR B.

[planetf1]

Moved to ready for review. This was held as draft pending Discussion #1166 — whether Granite 4.x needs its own formatter. The tests here cover Granite 3.2/3.3 warning branches only and are correct regardless of how that discussion resolves; any Granite 4.x work would land in PR B.

[planetf1]

Reverting to draft pending a design decision surfaced in Discussion #1166.

@jakelorocco confirmed there that the Granite32/Granite33 InputProcessor/OutputProcessor classes are not actually used by Mellea — the framework routes all models through the Intrinsics input/output processors instead. A quick grep confirms nothing in core, backends, stdlib, cli, or docs/examples ever imports or instantiates these classes; they are exported in mellea/formatters/granite/__init__.py but are otherwise dead code in the current execution paths.

This doesn't make the tests incorrect, but it does mean they cover warning branches that no production path currently reaches. Before asking reviewers to spend time here, the right call is to first settle in #1166 whether this code is intended to be wired up eventually, deprecated, or removed. Holding as draft until that's resolved.