fix: always cache contract WASM on GET regardless of return_contract_code

[sanity]

Problem

When a client sends a GET with return_contract_code: false, the node does not cache the contract WASM locally. This causes:

• SUBSCRIBE fails with "contract WASM/parameters not cached locally"
• The node cannot validate incoming updates for the contract
• The node cannot host the contract for other peers

The workaround (always setting return_contract_code: true) wastes bandwidth sending WASM to clients that already have it.

Approach

Separate the two concerns that return_contract_code was conflating:

1. Network request: Always fetch contract code from peers (fetch_contract: true internally) so the node can cache WASM for validation, subscription, and hosting
2. Client response: Strip contract code from the response when the client requested return_contract_code: false (bandwidth optimization)

Added a client_return_code field to GetOp that tracks the client's original preference. The node always fetches WASM from the network, but to_host_result() respects the client preference when building the response.

Testing

• Unit test: get_op_to_host_result_strips_contract_when_client_return_code_false - Verifies contract is included/excluded in client response based on client_return_code
• Unit test: start_op_always_fetches_contract_code - Verifies fetch_contract is always true internally even when client passes false
• Full cargo test -p freenet pass

Closes #3757

[AI-assisted - Claude]

[github-actions]

Rule Review: No warnings found; one minor note

Rules checked: git-workflow.md, code-style.md, testing.md, operations.md
Files reviewed: 3 (crates/core/src/operations/get.rs, crates/core/src/client_events.rs, crates/core/tests/error_notification.rs)

Warnings

None.

Info

• crates/core/src/operations/get.rs:3392,3413,3443,3470 — try_forward_or_return hardcodes client_return_code: true in all four result-building sites without a comment explaining the intent. In practice this is safe because relay nodes never call to_host_result(), but the rationale is non-obvious and could mislead a future reader who sees client_return_code being ignored here while everywhere else it propagates via self.client_return_code. A brief comment like // relay node: no client preference, always include code would clarify. (rule: code-style.md — comments explain WHY)

Overall: The fix is sound. fetch_contract is unconditionally set to true in start_op/start_op_with_id, the new client_return_code field propagates correctly through all state transitions in the originator path (self.client_return_code), and to_host_result() correctly strips the contract when the client requested return_contract_code=false. Two regression tests cover the exact behavioral change. The try_forward_or_return function correctly handles relay nodes (where no client preference applies).

---

Rule review against .claude/rules/. WARNING findings block merge.