fix(resources): fetch federated resource live when cached content is NULL

[Ewertonslv]

🔗 Related Issue

Refs #5450 (scoped to the NULL-content case — see Scope below; not an auto-close).

📝 Summary

In cache gateway mode, ResourceService.read_resource reads
content = resource_db.content for a federated resource. When both
text_content and binary_content are NULL (e.g. resources created via the
migration / re-discovery path, createdVia: rediscovery), the Resource.content
property raises ValueError("Resource has no content") before the RESOLVE
CONTENT block. The transport layer catches the exception and returns empty
content, so the client silently receives an empty read instead of the upstream's
real content.

Fix

Catch that ValueError in the cache-mode branch and, when the resource is
federated (has a gateway), build a metadata-only ResourceContent so the
existing RESOLVE CONTENT block fetches it live from the gateway — the same
path already used for resources whose cached content is an empty string. A
non-federated resource has nothing to fetch, so the original error is preserved
(re-raised).

Tests (before → after)

• ..._null_content_federated_fetches_live: NULL content + gateway → without the
  fix, ValueError propagates and the read is empty; with the fix, the content is
  fetched live via invoke_resource. (RED→GREEN verified locally with git stash.)
• ..._null_content_no_gateway_preserved: NULL content + no gateway → the
  "no content" error is preserved and no live fetch is attempted.

pytest tests/unit/mcpgateway/services/test_resource_service.py passes locally
(full file green, including module doctests via --doctest-modules).

🔎 Scope / follow-up (binary resources)

The issue also notes that binary federated resources read empty for a
separate reason: invoke_resource's SSE/StreamableHTTP helpers extract the live
payload with getattr(contents[0], "text") unconditionally, so a
BlobResourceContents (e.g. image/png) yields None. Fixing that cleanly
requires invoke_resource to signal which field (text vs blob) the upstream
returned — both are strings, so they can't be disambiguated after the fact — i.e.
a small change to its return contract, plus routing in the RESOLVE block. That is
a deliberate design decision I left out of this PR to keep it focused and
low-risk. Happy to follow up with that in a separate PR if you'd like — just let
me know your preference on the invoke_resource return shape.

📏 Reviewability

• This PR has one clear purpose
• The linked issue is not labeled triage
• Unrelated bugs or improvements are tracked in separate issues/PRs
• Tests are included with the code they validate
• If AI-assisted, I understand and can explain the generated changes

🏷️ Type of Change

• Bug fix