core: Reject incomplete gRPC responses

[neyy91]

Summary

Core gRPC responses can omit optional protobuf fields even when the RPC succeeds. BlockFetcher.IsSyncing currently dereferences a missing SyncInfo, and block reconstruction dereferences missing BlockPart values, causing the bridge to panic on incomplete responses.

Return contextual errors for missing sync information and block parts. The shared partsToBlock guard protects both block-by-height and block-by-hash streams without duplicate checks.

Related to #3816.

Testing

• go test ./core -count=1
• go test -race ./core -run '^(TestBlockFetcherRejectsMissingSyncInfo|TestPartsToBlockRejectsNilPart)$' -count=20
• go vet ./core
• golangci-lint run --new-from-rev=upstream/main ./core/...
• make lint-imports
• go mod tidy -diff
• ./scripts/check-go-mod-parity.sh

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 37.71%. Comparing base (2469e7a) to head (c6f738f).
⚠️ Report is 882 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5170      +/-   ##
==========================================
- Coverage   44.83%   37.71%   -7.12%     
==========================================
  Files         265      307      +42     
  Lines       14620    21350    +6730     
==========================================
+ Hits         6555     8053    +1498     
- Misses       7313    12287    +4974     
- Partials      752     1010     +258     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[greptile-apps]

Greptile Summary

This change makes Core response handling resilient to incomplete successful gRPC payloads: missing sync information and nil streamed block parts now produce errors rather than panics. No defect was established in the changed implementation.

T-Rex validation blocked

The focused Go checks did not reach completion because the validation tool hit its execution-step limit while compiling the ./core dependency graph. No completed command result was captured.

Confidence Score: 5/5

The updated nil guards match the affected dereference paths and turn malformed responses into explicit errors; no merge-blocking defect was identified.

There are no final review findings. The focused runtime check was interrupted during compilation, but that interruption did not reveal a product failure.

Files Needing Attention: No additional files need attention. core/fetcher.go and core/fetcher_nil_test.go contain the complete implementation and regression coverage for the changed behavior.

T-Rex Logs

What T-Rex did

• T-Rex attempted focused validation for malformed status responses and nil block parts, but the validation tool hit the execution-step limit during core dependency graph compilation.
• A before-safety run was executed to create an isolated HEAD^ worktree and run the baseline TestTrexBaselineNilResponsePanics, followed by an after-safety run that validated TestBlockFetcherRejectsMissingSyncInfo and TestPartsToBlockRejectsNilPart, with a plan to run a race check later.
• The execution logs recorded the commands and working directories for both before and after steps, but exit codes were not captured because compilation was still in progress when the run was halted.

_{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "fix(core): reject incomplete gRPC respon..." | Re-trigger Greptile}