Sanitize HTML in error responses to prevent reflected XSS

[nicholaspcr]

Summary

Backport of https://github.com/TheThingsIndustries/lorawan-stack/pull/4828.

Sanitize error responses to prevent reflected XSS from user-supplied input that flows into gRPC error messages and error detail attributes.

Changes

• Add sanitizingHTTPErrorHandler in pkg/rpcserver that HTML-escapes gRPC status messages before they are serialized to JSON, replacing runtime.DefaultHTTPErrorHandler.
• Add sanitizeAttributes and sanitizeAttributeValue in pkg/ttnpb/errors.go to HTML-escape string values in error detail attributes within ErrorDetailsToProto.
• Add tests for XSS sanitization in pkg/rpcserver, pkg/ttnpb, and pkg/webhandlers.

Testing

Steps

1. Run the new unit tests:

   go test ./pkg/rpcserver/ -run TestSanitizingHTTPErrorHandler -v
   go test ./pkg/ttnpb/ -run TestErrorDetailsToProtoXSSSanitization -v
   go test ./pkg/webhandlers/ -run TestNotFoundXSSSanitization -v

2. Start a local stack and send a request with an XSS payload in a field mask parameter:

   curl -s 'http://localhost:1885/api/v3/applications/test-app/devices?page=1&limit=10&field_mask=%3Cscript%3Ealert(1)%3C/script%3E' \
     -H 'Authorization: Bearer <token>' | jq .

3. Verify the response JSON contains <script> instead of <script>.

Results

All three tests pass. The error response body contains HTML-escaped entities and no raw <script> tags.

Regressions

• Error message formatting: the top-level message field in JSON error responses is now HTML-escaped, which may affect clients that display error messages as plain text (escaped entities like < would appear literally). This is the same behavior as the enterprise PR.
• Error detail attributes: string attribute values are now HTML-escaped in the protobuf conversion, which similarly may surface escaped entities in API consumers.

Notes for Reviewers

Checklist

• Scope: The referenced issue is addressed, there are no unrelated changes.
• Compatibility: The changes are backwards compatible with existing API, storage, configuration and CLI, according to the compatibility commitments in README.md for the chosen target branch.
• Documentation: Relevant documentation is added or updated.
• Testing: The steps/process to test this feature are clearly explained including testing for regressions.
• Infrastructure: If infrastructural changes (e.g., new RPC, configuration) are needed, a separate issue is created in the infrastructural repositories.
• Changelog: Significant features, behavior changes, deprecations and fixes are added to CHANGELOG.md.
• Commits: Commit messages follow guidelines in CONTRIBUTING.md, there are no fixup commits left.