Add request timeout, error handling, and retry to KGClient

[apdavison]

The aim is to make the KGClient more robust, with better handling of network errors and dropped responses from the KG.

• kg_core sets no timeout on its outbound HTTP requests and exposes no supported way to configure one, so a request that loses its connection mid-flight (e.g. switching wifi networks) hangs forever instead of failing. This patches kg_core to apply a default 300s timeout, configurable via a new request_timeout kwarg on KGClient.
• Network failures (lost connection, no response within the timeout) now raise a clear KGConnectionError instead of a raw requests exception. Two independent layers produce it, so translation keeps working even if kg_core's private internals change and the deeper patch can no longer be applied.
• Read-only and query-only KGClient methods (list, query, instance_from_full_uri, retrieve_query, user_info, spaces, space_info, is_released, token) now retry automatically with exponential backoff on KGConnectionError, via new max_retries/retry_backoff kwargs (defaults: 2 retries, 5s base). Methods that modify the KG are deliberately never auto-retried, since replaying a write risks duplicating or corrupting data if the original request actually succeeded but its response was lost.

---

The default timeout is long: 300 seconds. This is to ensure we wait long enough to get the KG response, but we don't wait forever. This is based on the following timings:

Method: raw HTTP GET requests to the KG core API's /v3-beta/instances endpoint for the File type (openMINDS type with very many instances), using requests directly with a large client-side timeout (well beyond any expected server response time).

Pre-production (core.kg-ppd.ebrains.eu):

• size=1, no count: dropped at 50.09s and 50.12s (two separate trials). Connection aborted with no HTTP response ("RemoteDisconnected").
• Same query, once "warm": succeeded consistently at ~11-12s (repeat identical queries appear to hit a query/result cache).
• Fresh query, size=50: succeeded at 23.16s.
• Fresh query, size=500: dropped again at 50.09s (same failure, independent of page size/shape).
• Conclusion: ppd has a hard, consistent ~50-second cutoff (three drops landed within 30ms of each other) - almost certainly a gateway/reverse-proxy in front of the KG core API, not the KG's own query engine. Anything that doesn't get a response within ~50s is silently killed with no HTTP status at all.

Production (core.kg.ebrains.eu):

• size=1, no count: 193.91s, succeeded.
• Same query repeated: 32.92s, 27.95s, 23.57s, 24.43s - much faster once warm, but still slower than ppd's warm case.
• size=500, fresh: 119.69s, succeeded.
• size=1, returnTotalResults=true: 121.24s, succeeded (total count: 956,369 File instances).
• size=1000, returnTotalResults=true, fresh: 78.62s, succeeded.
• size=5000, returnTotalResults=true, fresh: 142.90s, succeeded.
• Conclusion: no drops in 9 trials up to ~194s. Either there's no fixed gateway cutoff on production, or its threshold is well above what was tested.

Implications:

• The ~50s ppd cutoff is environment-specific, not a general KG timeout to design around.
• A client-side default timeout needs to tolerate production's observed range (up to ~194s) without spuriously killing a legitimate slow-but-successful query: hence the 300s default chosen for request_timeout, comfortably above the slowest observed case.
• Because a query that eventually succeeds when "warm" (e.g. ~12-30s) can fail cold (timeout, or a dropped connection on ppd), retrying a failed read/query-only request is often enough to succeed quickly on the second attempt - the motivation for the retry behaviour added on top of the timeout/error-handling work.