Return JSON when IA->OL unlink request fails

[jimchamp]

Follows #11230

Updates record unlink handler such that it returns JSON when an error occurs.

Technical

Testing

Screenshot

Stakeholders

[Copilot]

Pull request overview

Updates the IA→OL unlink internal API handler to return JSON responses when errors occur, aligning error handling with API consumers expecting JSON payloads.

Changes:

• Adds Content-Type: application/json headers to several web.HTTPError responses in /api/unlink.
• Ensures some error cases (400/409/500) include JSON-encoded error payloads.

[Copilot]

401 Unauthorized sets Content-Type: application/json but doesn't provide a JSON body (data=...). This can produce a response that advertises JSON but isn't valid JSON (and may still be the default error payload). To ensure clients can always parse errors, include a JSON data payload (consistent with other handlers in this file, e.g. the 404s that return data="{}").

Suggested change

	raise web.HTTPError("401 Unauthorized", {"Content-Type": "application/json"})
	raise web.HTTPError(
	"401 Unauthorized",
	{"Content-Type": "application/json"},
	data=json.dumps({"error": "Unauthorized"}),
	)

[Copilot]

msg.split("|") will raise ValueError if the message contains more than one | (which HMACToken.verify permits, since it uses rsplit(..., maxsplit=1)). That would lead to an unhandled exception (likely a 500 / non-JSON response), undermining the goal of returning JSON on failures. Parse with rsplit('|', 1) (or otherwise validate the split) and convert any parsing errors into a JSON 400 Bad Request.

[Copilot]

404 Not Found sets Content-Type: application/json but doesn't provide a JSON body (data=...). This can result in clients receiving a non-JSON body while attempting to parse JSON. Consider returning at least {} or an {"error": ...} payload (similar to other JSON 404s in this file).

[RayBB]

I was looking at this code today actually and wondering how we decide to return JSON or not. And I'm glad you're updating it to return JSON. This makes a lot of sense to me and will make it easier to do the migration for FastAPI.