fix(kms): auto-append /prpc to onboard source_url

[kvinwang]

Summary

• Normalize source_url in the Onboard RPC handler by auto-appending /prpc when missing
• Matches the existing pattern in dstack-util (main.rs:543-546) and system_setup.rs
• Allows callers to pass just the base URL (e.g. https://kms.example.com:9201) without knowing the internal /prpc path prefix

Context

Currently source_url is passed verbatim to RaClient::new(), which constructs URLs as {source_url}/{method}?json. Without the /prpc suffix, requests hit the wrong path and get 404s.

The web UI (onboard.html) works around this by appending /prpc in JavaScript, but direct API callers (e.g. curl) must know to include it.

Test plan

• cargo check passes (verified locally)
• Onboard with source_url = "https://host:9201/prpc" still works (no double /prpc)
• Onboard with source_url = "https://host:9201" now works (auto-appended)
• Onboard with source_url = "https://host:9201/" now works (trailing slash trimmed)

[sentry]

Bug: The URL normalization logic incorrectly handles a source_url ending with /prpc/, resulting in a malformed URL like .../prpc/prpc.
_{Severity: MEDIUM}

Suggested Fix

Reverse the order of operations in the URL normalization logic. First, call trim_end_matches('/') on the source_url to remove any trailing slashes. Then, perform the ends_with("/prpc") check to decide whether to append /prpc. This ensures that inputs like https://host/prpc/ are correctly handled.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: kms/src/onboard_service.rs#L80-L84

Potential issue: The URL normalization logic has a flaw in its order of operations. When
a `source_url` ending in `/prpc/` (with a trailing slash) is provided, the code first
checks if the string `ends_with("/prpc")`. This check returns false due to the trailing
slash. Consequently, the code enters the `else` block, where it trims the trailing slash
and then appends another `/prpc`. This results in a malformed URL, such as
`https://host/prpc/prpc`, which will cause subsequent API calls to fail with 404 errors,
breaking the onboarding functionality for that user.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[sentry]

Bug: URL normalization incorrectly appends a duplicate /prpc suffix if the input URL already ends with /prpc/, causing downstream requests to fail.
_{Severity: MEDIUM}

Suggested Fix

The normalization logic should be adjusted to correctly handle URLs with a trailing slash. A robust approach is to first trim any trailing slashes from request.source_url, and then check if the resulting string ends with /prpc before conditionally appending it. This ensures that inputs like .../prpc/ are correctly normalized to .../prpc.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: kms/src/onboard_service.rs#L80-L83

Potential issue: The URL normalization logic in `onboard_service.rs` incorrectly handles
URLs that end with `/prpc/`. The check `request.source_url.ends_with("/prpc")` returns
false for such an input due to the trailing slash. This causes the code to enter the
`else` block, which trims the trailing slash and then appends another `/prpc` suffix.
This results in a malformed URL like `https://host/prpc/prpc`. Subsequent RPC calls
using this URL will fail with a 404 error, breaking the functionality for clients that
provide URLs with a trailing slash, such as direct API callers or configurations.

_{Did we get this right? 👍 / 👎 to inform future reviews.}