feat(validator): explicit description max-length feedback (#1184)

[rhinocap]

Closes #1184

Why

Today when a publisher submits a server.json with a description (or any string field) over the schema's maxLength, they get the upstream jsonschema library's terse phrasing:

length must be <= 100, but got 312

…with no field name in the message itself, and no concrete suggestion of what to send instead. The reporter on #1184 had to discover the 100-char limit by trial and error.

What

Rewrites the message in addDetailedErrors to be self-contained and actionable:

field "description" is too long: 312 chars (max 100). Truncate to: "<first 97 chars>..."

Done by detecting maxLength errors via KeywordLocation suffix, looking up the offending value at InstanceLocation, and emitting an explicit message with field name, observed length, max, and a rune-safe truncation hint that fits within maxLength. Applies to any string field with a maxLength constraint — description is just the trigger case.

The bracket path (e.g. description) is still set as Issue.Path, so any tooling that reads the structured ValidationIssue is unaffected.

Test plan

• New TestValidateServerJSON_MaxLengthFeedback constructs a server.json with a 312-char description and asserts the new message format (field name, observed length, max, truncation suggestion ending in ..., and absence of the raw jsonschema phrasing).
• New TestExtractFieldName covers leaf-name extraction from bracket paths.
• New TestTruncateForSuggestion covers the rune-safe truncation helper, including unicode and very-small maxLen.
• go test ./internal/validators/... passes locally.
• go build ./... clean.
• golangci-lint run no new findings (baseline 51 issues unchanged).

[rhinocap]

Hey @rdimitrov — CI is green and the PR is mergeable. Happy to defer, split, or merge as-is per your preference. Let me know how you'd like to proceed.