fix: surface actual API errors instead of generic 'No valid XML' message

[octo-patch]

Fixes #493

Problem

When wiki generation fails due to upstream API errors (e.g. rate limiting 429), the frontend only shows a generic message:

No valid XML found in response
Please check that your repository exists and is public...

The actual error (e.g. Error code: 429 - RPM limit reached) is only visible in container logs, making debugging very difficult. Users are misled into thinking their repository URL is wrong.

Solution

After the existing specific error checks (OPENAI_API_KEY missing, Ollama model not found), before throwing the generic error, the code now attempts to extract and surface the actual API error message from the response text:

1. First checks for provider-specific errors matching Error with <Provider> API: <message> (e.g. Error with Openai API: Error code: 429 - ...)
2. Falls back to checking for general \nError: <message> patterns
3. Only falls back to the generic 'No valid XML found in response' if no API error is detected

Testing

• When an API returns a rate limit error (429), users will now see Error with Openai API: Error code: 429 - {'error': {'message': 'RPM limit reached'}} instead of the misleading generic message
• Existing behavior is preserved for cases where no API error is present (e.g. true XML parsing failures)
• The existing specific error checks (missing API key, Ollama model not found) are unaffected

[gemini-code-assist]

Code Review

This pull request improves error handling when parsing the wiki structure by attempting to extract and surface specific API or general error messages from the response text. Feedback was provided to make the error-matching regular expressions more robust by accounting for hyphens in API provider names and ensuring matches work at the start of the response string.

[gemini-code-assist]

The regex for apiErrorMatch might fail if the provider name contains hyphens (e.g., "Google-Cloud"). Additionally, for consistency with the general error check and to ensure the error is captured even if it's at the very beginning of the response, consider using (?:^|\n) as a prefix.

Suggested change

	const apiErrorMatch = responseText.match(/Error with [\w][\w ]*API:\s*[^\n]+/);
	const apiErrorMatch = responseText.match(/(?:^|\n)Error with [\w][\w -]*API:\s*[^\n]+/);

[gemini-code-assist]

The regex for generalErrorMatch currently requires a leading newline (\n). If the API response starts directly with the error message (e.g., "Error: ..."), this check will fail. Using (?:^|\n) allows the match to occur at the beginning of the string or after a newline, making the error detection more robust.

Suggested change

	const generalErrorMatch = responseText.match(/\nError:\s*[^\n]+/);
	const generalErrorMatch = responseText.match(/(?:^|\n)Error:\s*[^\n]+/);