feat(diagnostics): stabilise selected validation diagnostics

[LMLiam]

Outcome

The first public validation surfaces use stable diagnostic identities and source locations without creating one diagnostic model for the complete repository.

First APIs

• Review the existing String.validate(...), ValidationResult.diagnostics, and MiniMessageDiagnostic surface.
• Define the diagnostic bridge that the catalogue compiler in feat(catalog-compiler): generate a typed message catalog from resources #49 and the cross-locale checks in feat(catalog-compiler): report cross-locale catalogue completeness #504 need.
• Keep MiniMessageToDslConversionException and unrelated exceptions out of scope unless a real caller needs structured data from them.

Design gate

Complete #55 first. Then show realistic call sites for runtime validation and build diagnostics. Decide whether the existing sealed diagnostic types can evolve without a new public abstraction.

Contract

• Give each selected failure a stable identity that is independent of prose.
• Use a half-open source range with a named source identifier when the failure refers to source text.
• Keep the human-readable message as presentation data.
• Preserve the existing MiniMessageDiagnostic behaviour unless the approved design replaces it.

Non-goals

• Do not create a repository-wide diagnostic framework.
• Do not assign codes to every exception.
• Do not make internal matcher failures public.

Dependencies

Blocked by #55. Complete the design before #49 and #504 define their final diagnostic output.

Acceptance criteria

• Approved call sites name each public API that uses the contract.
• Diagnostic identity and source range remain stable when prose changes.
• Runtime and build diagnostics use one deliberate bridge where their needs overlap.
• Reduced invalid-input fixtures cover each selected diagnostic.
• Public declarations have KDoc and compatibility coverage.