[BUG] Endpoint gutters and OpenAPI readers invent a class-prefix URL for unreadable mapping paths #709

Component

Navigation gutter; OpenAPI

Problem details

A method with a declared but unreadable mapping path is treated as if it declared no path. Endpoint Actions, Run in Swagger, and SpringWebUtil.getEndpointInfo fall back to an empty method path and therefore offer the class-level prefix as the endpoint URL. There is no evidence that the application serves that URL.

This is pre-existing, not a regression introduced by #707. That PR fixed the same distinction in the endpoint MODEL, but left these three readers unchanged in behavior.

Verified on main e73a5a7fc:

• ControllerEndpointActionsLineMarkerProvider.kt:56–57: mapping.paths.firstOrNull()?.path ?: "", then joins the class prefix for Endpoint Actions / OpenAPI generation.
• EndpointRunLineMarkerProvider.kt:74: HandlerMethods.methodMapping(...).paths.firstOrNull()?.path ?: "" in getUrlPath, then joins the class prefix for Run in Swagger.
• SpringWebUtil.kt:348–349: mapping.paths.firstOrNull()?.path ?: "" in getEndpointInfo, then joins its caller-supplied prefix.

Steps to reproduce

1. Open a Spring controller with a readable class prefix and a method path the IDE cannot evaluate:

@RestController
@RequestMapping("/api")
class SampleController {
    @GetMapping(SOME_UNRESOLVED_CONST)
    String sample() { return "ok"; }
}

2. Inspect Endpoint Actions / Run in Swagger and the URL supplied to OpenAPI generation (or call SpringWebUtil.getEndpointInfo with prefix /api).
3. Observe a fabricated /api URL, whereas the endpoint model correctly omits the unreadable mapping after fix: Read method request mappings from the single annotation Spring registers (#672) #707.

The unresolved constant is a minimal static-analysis reproduction, not a claim that this uncompilable snippet starts successfully. An unreadable path does not justify inventing a served URL.

Expected: suppress the URL-dependent marker/action or return no EndpointInfo when a path is declared but no path can be read. Continue to accept a genuinely pathless @GetMapping and an explicit empty path, which legitimately use the class prefix.

Additional information

Apply the same distinction already introduced by #707 through HandlerMethods.MethodMapping.pathsDeclared and used by SpringWebUtil.requestMappingOf (lines 380–383):

• no declared path → empty method segment is valid;
• declared path but empty evaluated paths → unknown/unreadable, not an empty segment;
• readable path (including "") → use that path.

Update all three readers, preserving readable-path behavior. Add Java/Kotlin regression coverage for unresolved method paths with a class prefix, genuinely pathless mappings, explicit empty paths, and ordinary readable paths. This task concerns the remaining consumers, not redoing the endpoint-model fix.

Refs #672 and #707 (#707). #647 covers other OpenAPI issues, not this path fallback.

Plugin version

Source inspection of main at e73a5a7fc (merged #707); no installed/published plugin version was supplied or assumed. Main-only fix area: HandlerMethods exists on no release/* branch. The underlying fallback predates #707; release-branch behavior was not investigated.

IDE name and build

IntelliJ IDEA 2026.2.3 (reported workspace environment). Edition and exact build number were not supplied; not guessed. Evidence here is read-only code inspection, not an interactive IDE reproduction.

Build system

Gradle (plugin repository). No build or test was run; the consumer project's build system is unspecified and is not material to this reader defect.

Additional context

Duplicate searches across all states checked unreadable/unresolved mapping paths, phantom endpoints, pathsDeclared, class-level prefix and unresolved Swagger. #672 is the broader composed-annotation work; #707 explicitly records this remaining pre-existing gap.