Approve. Closes a real (if narrow) consensus-correctness gap — pre-PR return nil after a GetBlockHeader flake signalled "block valid" without ever consulting blockMeta.Invalid. New ServiceError is the right answer and restores symmetry with the revalidation branch at :1192-1196. Test exercises the fixed path exactly and pins ErrServiceError wrapping.

Two notes worth recording:

• The asymmetry with GetBlockExists warn-and-proceed at :1170-1175 is intentional and correct: existence unknown → revalidate (consensus-safe via runOncePerBlock + StoreBlock duplicate-rejection); validity unknown after exists=true → fail-closed. One-line code comment at :1172 documenting the asymmetry would help future maintainers not unify them.
• Sonar's reliability=C is a filename-convention false positive — the package consistently uses PascalCase for type-bound area tests (BlockValidation_test.go, BlockValidation_difficulty_test.go) and snake_case for bare-topic tests (catchup_*, fork_manager_*). The new file matches the area-test pattern; suggest overriding the Sonar gate rather than renaming.

Optional follow-ups, none gating:

• Retry-with-backoff on GetBlockHeader at :1177 and :1192 (2-3 retries at 50/100/200ms). A transient gRPC blip shouldn't propagate as ServiceError.
• Latent meta==nil but err==nil gap at :1182 — falls through to return nil, same shape as the bug just fixed but with a silent-nil-meta failure mode. Worth a defensive guard + test.

Anything in the #4581 threat model worth adding to the PR description? Would help future readers since the issue isn't accessible to most reviewers.