fix(core): preserve remote transaction errors

[xternet]

Summary

Surfpool's remote getTransaction path previously treated every client error as a missing transaction. This conflated two different RPC outcomes:

• a valid JSON-RPC null, meaning the transaction is unavailable; and
• transport, HTTP, provider, or decoding failures, meaning the lookup did not complete reliably.

The Solana RPC client convenience method deserializes directly into a concrete transaction, so a valid null arrives through its error path too.

Change

• Deserialize the raw getTransaction response as Option<EncodedConfirmedTransactionWithStatusMeta>.
• Keep valid null mapped to GetTransactionResult::None.
• Propagate genuine provider failures through the locker's existing SurfpoolResult boundary.
• Preserve the published SurfnetRemoteClient::get_transaction return type with a compatibility wrapper; the new fallible method is crate-private.
• Sanitize transport failures before putting them in client-visible JSON-RPC error data. Reqwest errors can include the full datasource URL, so callers receive the useful failure category plus scheme/host, never userinfo, path, or query credentials.

Regression coverage

• A recorded null response remains None and verifies the exact outgoing GetTransaction request/config.
• A provider failure reaches the locker caller instead of becoming None.
• A real local HTTP 401 response is requested through a URL carrying credentials in userinfo, path, and query; the propagated error retains 401 Unauthorized and the sanitized host but omits every secret.

Validation

• cargo test -p surfpool-core surfnet::remote::tests::a_ -- --test-threads=1 — 5 passed
• cargo test -p surfpool-core --no-default-features surfnet::remote::tests::a_ -- --test-threads=1 — 5 passed
• cargo +nightly fmt --all -- --check
• cargo clippy -p surfpool-core --lib --no-default-features — completed with existing repository warnings only
• git diff --check

This branch and #762 both add tests to surfnet/remote.rs; whichever lands second may need a trivial rebase, but the production changes are independent.

[greptile-apps]

Greptile Summary

This PR distinguishes valid null remote transaction responses from genuine datasource failures while preserving the existing public client API.

• Deserializes raw getTransaction responses as optional transactions.
• Propagates provider failures through the locker's existing result boundary.
• Sanitizes client-visible datasource errors to retain useful categories without exposing URL credentials.
• Adds regression coverage for null responses, propagated failures, and credential redaction.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
crates/core/src/error.rs	Adds a transaction-specific internal error constructor that includes the requested signature and already-sanitized remote failure description.
crates/core/src/surfnet/locker.rs	Changes remote transaction fallback to propagate genuine provider failures while preserving successful and missing-transaction results.
crates/core/src/surfnet/remote.rs	Introduces fallible optional-response handling and category-based datasource error sanitization; the previously reported provider-reflection disclosure is addressed by discarding provider-controlled RPC and custom error text.

_{Reviews (4): Last reviewed commit: "fix(core): log sanitized transaction err..." | Re-trigger Greptile}

[koriyoshi2041]

Validated exact head b1262b94f0 locally. cargo test -p surfpool-core surfnet::remote::tests::a_ -- --test-threads=1 passed 5/5: valid JSON-RPC null remains a missing transaction, provider failures reach the locker caller, and the 401/timeout paths retain useful failure categories without disclosing datasource userinfo, path, or query credentials. The post-review change also removes provider-controlled RpcError/Custom text rather than trying to redact only a full URL. git diff --check is clean; the only build output was the existing unrelated dead-code warning in the integration test module.

[MicaiahReid]

@xternet I can't merge without verified commit signatures: https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification

[xternet]

@MicaiahReid All three updated commits are now SSH-signed and shown as Verified by GitHub. Thanks.