fix: normalize raw local path base URI for OpenAPI 3.1 ref resolution (#2365)

[seonwooj0810]

Fixes #2365

Root cause

OpenAPIV3Parser.readLocation(...) accepts a raw local filesystem path, and that path becomes the base URI for OpenAPI 3.1 reference resolution. Resolution then builds java.net.URI instances from the base in several places (ReferenceUtils.resolve/toBaseURI and Visitor#readURI). When the raw path contains a character that is illegal in a URI — most commonly a space — those new URI(...) calls throw URISyntaxException: Illegal character in path. The exception is caught in ReferenceVisitor and recorded as a parse message, so a self-contained single-file spec resolving same-file refs (e.g. #/components/responses/...) returns a result polluted with an Illegal character in path error.

Fix

Normalize the location once, at the entry to resolve(...): if the location is not already a valid URI, convert it to a proper file: URI via Paths.get(location).toUri() so the base is URI-safe everywhere downstream. Locations that already parse as a URI (including scheme-less relative paths without illegal characters) are left untouched, so existing behavior is unchanged.

Test evidence

Added a regression test OpenAPIV31RawPathWithSpacesTest#resolveSameFileReferenceFromRawPathWithSpaces that writes a single-file 3.1 spec with same-file response/schema $refs into a temp directory whose path contains spaces and asserts the parse result carries no Illegal character in path message. It fails before the change (Illegal character in path at index 12: ...) and passes after.

Verification done: full swagger-parser-v3 module test suite green (584 + 25 tests, 0 failures) with the fix; the new regression test fails before / passes after. (The safe-url-resolver module has pre-existing JDK 25 mock failures unrelated to this change.)