fix: discovery no longer mistakes 404 error pages for real endpoints

[GovindarajanL]

Fixes #73

Summary

exploreApiRoots() and testCommonResourcePatterns() treated any non-empty HTTP response body as evidence of a real endpoint, without checking the status code. Since most servers return a non-empty body on a 404 (an error page), every generic path guess against a reachable server was misread as "found something here".

Reproduction

Scanned OWASP crAPI (local docker-compose stack, no self-published OpenAPI spec). Auto-discovery reported:

Found potential API root at: http://127.0.0.1:8888//api
Found potential API root at: http://127.0.0.1:8888//api/v1
...
Discovered 8 unique endpoints

Every single one was a 404 page from crAPI's nginx gateway for a generic guessed path — none are real crAPI routes (which live under /identity/api/..., /community/api/..., /workshop/api/...). The scan then ran with 0 real coverage while logging as if discovery had succeeded, indistinguishable from "target is secure".

Fix

Both methods now gate on the response status code (2xx) via getWithStatus(), not just body non-emptiness. Also strengthens the "nothing discovered" warning to explicitly name --endpoints-file/--config as the fix, instead of silently falling back to a generic hardcoded endpoint list with no indication that coverage will be poor.

Verification

• Re-ran auto-discovery against crAPI after the fix: correctly reports "No endpoints discovered" instead of 8 false hits.
• New regression test reproduces the exact scenario: a target where every generic path guess returns a non-empty 404, asserting none of them are reported as discovered endpoints.
• Full suite passes (241 tests).

Test plan

• mvn test passes
• Re-ran auto-discovery against crAPI with the fixed jar — 0 false endpoints, honest "no endpoints discovered" warning instead