fix(indexing): reject blank document input consistently across formats

[adityamparikh]

Summary

Rebased onto main after #176, which added blank checks to the JSON and CSV creators. That left the three formats with three different messages for the same condition, and JSON/CSV still NPE on null:

	check on main	message on main
JSON	json.isBlank()	JSON input cannot be empty
CSV	csv.isBlank()	CSV input cannot be empty
XML	xml == null || xml.trim().isEmpty()	XML input cannot be null or empty

XML's check also lives in IndexingDocumentCreator rather than the creator itself, so the formats disagree on location as well as wording.

Changes

• Move the check onto the SolrDocumentCreator contract as a shared requireContent(content, format) helper; call it from all three creators.
• One message shape everywhere: "<FORMAT> input cannot be null or empty" — the wording XML already used, so existing XmlIndexingTest assertions are unchanged.
• Close the null gap for JSON and CSV (see below).
• Correct the SolrDocumentCreator javadoc, which documented three mutually exclusive contracts (handle null gracefully / return empty list / throw IllegalArgumentException), none matching the implementations.

Input	After #176	This PR
...FromJson(null)	NullPointerException	DocumentProcessingException: JSON input cannot be null or empty
...FromJson("")	DocumentProcessingException: JSON input cannot be empty	DocumentProcessingException: JSON input cannot be null or empty
...FromCsv(null)	NullPointerException	DocumentProcessingException: CSV input cannot be null or empty
...FromCsv("")	DocumentProcessingException: CSV input cannot be empty	DocumentProcessingException: CSV input cannot be null or empty
...FromXml(null or "")	DocumentProcessingException: XML input cannot be null or empty	(unchanged)

Why a runtime null check in @NullMarked code

The package is @NullMarked with NullAway wired as a build error, so this may look redundant — that is presumably why #176 wrote json.isBlank() with no null guard. But NullAway is a closed-world compile-time analysis: it only binds callers the compiler can see, and emits no runtime check (unlike Kotlin, which compiles Intrinsics.checkNotNullParameter into public API boundaries).

These creators are reached from @McpTool methods whose arguments the Spring AI annotation runtime resolves reflectively: AbstractMcpToolMethodCallback looks each parameter up in the request's argument map and passes the result straight to buildTypedArgument, which returns null for a null input. A missing or null JSON value therefore arrives as null regardless of the annotation. @McpToolParam(required = true) only marks the parameter required in the advertised JSON schema; the server does not validate incoming arguments against it.

The rationale is recorded on requireContent so it doesn't get "cleaned up" later.

Test plan

• ./gradlew build passes (rebased onto c1c2a8e)
• New JsonIndexingTest (4 tests) and 3 added CsvIndexingTest cases mirror the existing XML null/empty/whitespace trio
• XmlIndexingTest (16 tests) unchanged and green
• No regressions

Companion to #108, which applies the same treatment to collection-name validation and uses the same message wording.

🤖 Generated with Claude Code