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).

Fresh PR replacing #5467. That PR was closed on 2026-08-31 during the housekeeping pass on long-open contributions. GitHub refused to re-open it after the rebase (a force-push makes a closed PR non-reopenable), so this is the "or open a fresh one" path @jonpspri suggested. The change itself is unchanged — only rebased.

On the "open an issue describing the problem" step: #5450 already exists and is still open, so I did not file a duplicate. Happy to open a fresh one if you'd rather.

📝 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.
• ..._null_content_no_gateway_preserved: NULL content + no gateway → the
  "no content" error is preserved and no live fetch is attempted.

🔄 Rebase notes (2026-08-31)

Rebased onto current main (ffcc0822) — clean rebase, no conflicts. Re-verified
against today's main:

• Still reproducible. Cache mode still does a bare content = resource_db.content,
  so a federated row with NULL cached content still raises
  ValueError: Resource has no content instead of proxying upstream.
• Regression proof still holds. With the production hunk reverted to main,
  ..._null_content_federated_fetches_live fails with that ValueError; with the
  hunk applied, both new tests pass.
• pytest tests/unit/mcpgateway/services/test_resource_service.py — 309 passed.
• ruff check, ruff format --check and black --check clean on both touched files.

Coordination note (unchanged): this and the direct_proxy fix for #5451 both touch
read_resource in resource_service.py, but they fix different bugs on different
code paths and their hunks do not overlap, so they merge cleanly in either order and
neither depends on the other. Kept separate deliberately, per the one-concern rule.

Also: #5450 is no longer labeled triage (it is bug / COULD now), which was the
concern I flagged in my comment on the original PR.

🔎 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