Report a friendly error for snapshot branches missing on swift.org

[adityasingh2400]

When you ask swiftly for a snapshot branch that isn't published on swift.org, you currently get a raw, low-level HTTP error rather than something you can act on:

$ swiftly list-available 9.9-snapshot
Error: Unexpected response, expected status code: ok, response: undocumented(statusCode: 404, OpenAPIRuntime.UndocumentedPayload(...))

The same thing happens for swiftly install <branch>-snapshot and when updating a snapshot whose branch has aged out.

The root cause is that HTTPRequestExecutorImpl.getSnapshotToolchains forwarded the response straight through response.ok.body.json. swift.org returns a 404 for the dev-toolchains endpoint when the branch doesn't exist (or is older than the supported main and previous x.y releases), and .ok then throws the generic OpenAPI runtime error.

Interestingly, install, list-available, and update already catch SwiftlyHTTPClient.SnapshotBranchNotFoundError and turn it into a clear, actionable message. But nothing ever threw that error, so all three catch blocks were dead code.

This change detects the 404 from listDevToolchains and throws SnapshotBranchNotFoundError, reconstructing the branch from the SourceBranch that was requested so the message names the branch the user actually typed. The reconstruction is the inverse of the SourceBranch mapping already done in getSnapshotToolchains. Non-404 responses (for example a 5xx server error) keep propagating as before, so a transient server problem is not misreported as a missing branch.

With the fix, the same command now reports:

$ swiftly list-available 9.9-snapshot
Error: The snapshot branch 9.9 development was not found on swift.org. Note that snapshot toolchains are only available for the current `main` release and the previous x.y (major.minor) release.

Verification: added SnapshotBranchNotFoundTests, which feeds a synthetic 404 listDevToolchains response through the response handler and asserts it maps to SnapshotBranchNotFoundError with the correct branch (both main and a release branch), that a 200 still returns the toolchains untouched, that a 500 is not reported as a missing branch, and that the SourceBranch to branch reconstruction round-trips. The new tests fail before the change (the raw 404 error escapes) and pass after. The rest of the suite (171 tests across 21 suites, excluding the network-tagged HTTPClientTests) continues to pass, and swiftformat reports no changes for the touched files.

Resolves #539

[etcwilde]

It looks like this function is just wrapping an if-statement. Lets inline the if-statement back up into the original function.

[adityasingh2400]

Done in de066ad. Inlined the 404 check straight into getSnapshotToolchains and removed the devToolchains helper.

One heads-up on the tests: that helper was also the seam the unit tests used to exercise the 404 to SnapshotBranchNotFoundError mapping offline, and the suite has no mock ClientTransport to drive getSnapshotToolchains without a network call. So with the helper gone I dropped the response-mapping tests and kept branchReconstructionRoundTrips, which covers the part with actual logic (rebuilding the requested branch so the error carries it). The 404 check itself is now a one-line inline pattern match.

If you would rather keep that path covered, I am happy to add a small mock-transport test that returns a 404 and asserts getSnapshotToolchains throws the typed error. Let me know your preference.