fix(retrieval): name the link when process/url cannot fetch it (#31354)

Attaching a link in chat or to a knowledge base that cannot be fetched (closed port, blocked by the fetch filter, an HTTP error such as 404) showed the toast "Error processing URL", which never said which link failed or that fetching it was the problem.

The fetch step now answers with "Could not read content from <url>", the same message process/web gives for a link it cannot read, so both endpoints report a dead link the same way. The too-large 413 still passes through unchanged, and a working link returns exactly what it did before.

The new handler covers only the fetch. Rewording the endpoint's existing catch-all would be one line, but that handler also receives database errors from the config and file lookups, which would then be reported as an unreadable link.

Related to #31347

backend/open_webui/routers/retrieval.py

@@ -2376,7 +2376,16 @@ async def process_url(
             }
 
         config = await get_retrieval_config()
-        url_result = await _fetch_url(form_data.url, config.FILE_MAX_SIZE)
+        try:
+            url_result = await _fetch_url(form_data.url, config.FILE_MAX_SIZE)
+        except HTTPException:
+            raise
+        except Exception as e:
+            log.exception(e)
+            raise HTTPException(
+                status_code=status.HTTP_400_BAD_REQUEST,
+                detail=ERROR_MESSAGES.DEFAULT(e, f'Could not read content from {form_data.url}'),
+            )
 
         if url_result['kind'] == 'web':
             result = await process_web(request, form_data, process=process, user=user)