fix(#3412): swarm-controller answers errors as RFC 9457 problem+json

Its three error paths returned a bare string with a status code, which forces
a caller to treat the whole body as prose. hive-c0re converted some time ago,
so swarm-controller was the last backend on the old shape -- and it is the one
behind the hive status page's 503, where the body is frequently the entire
diagnosis rather than a summary.

Adds the commitment to docs/conventions.md, since it was implied by the code
in one daemon and written down nowhere: an endpoint of ours answering with a
bare string is a bug to file, not something callers work around.

The test asserts the rendered response -- media type plus an addressable
detail -- rather than the problem_details value, because a handler that built
the value correctly and then returned it as a string would satisfy a test
written against the type alone.

swarm-controller/Cargo.toml

@@ -27,6 +27,10 @@ forgejo-api.workspace = true
 # raw bytes.
 base64.workspace = true
 futures-util.workspace = true
+# RFC 9457 `application/problem+json` error bodies. Same version + `axum`
+# feature as hive-c0re: the two daemons answer the same operator UIs, so a
+# reader that handles one's failures has to handle the other's.
+problem_details = { version = "0.9.0", features = ["axum"] }
 # The graph itself, held directly rather than behind a c0re-style wrapper
 # module — that layering (`hive-c0re::job_queue`) is partially legacy (predates
 # `hive-jobq`'s extraction into its own crate) and this daemon does not need it