silentpayments: add hash ctx (SHA256 compression override) test #1940

This PR adds a test to check that the ctx-provided SHA256 compression override takes effect for the following silentpayments module API functions:

• secp256k1_silentpayments_label_create (hash result is used for calculating the label tweak)
• secp256k1_silentpayments_sender_create_outputs (hash results are used for calculating the input hash and output tweak)
• secp256k1_silentpayments_recipient_prevouts_summary_create (hash result is used for calculating the input hash)
• secp256k1_silentpayments_recipient_scan_outputs (hash result is used for calculating the output tweak)

With #1866 for musig and this PR, all public functions that take use of the SHA256 compression override should be covered by tests.

In silentpayments_ctx_sha256, the check on secp256k1_silentpayments_recipient_scan_outputs currently only exercises the negative path (n_found_outputs == 0) against the default output. If scan_outputs encountered an internal calculation failure or returned early under custom compression, an assertion on zero matches alone could pass vacuously.

Pairing this with a symmetric positive check confirms that sender output generation and recipient scanning remain isomorphic under the custom compression hook.

    /* When scanned against the custom output and custom prevouts summary under the same
     * override, the recipient successfully identifies the payment. */
    tx_outputs[0] = &output_custom;
    CHECK(secp256k1_silentpayments_recipient_scan_outputs(ctx, found_outputs, &n_found_outputs, tx_outputs, 1, bob_scan_seckey, &prevouts_summary_custom, &bob.spend_pubkey, NULL, NULL) == 1);
    CHECK(n_found_outputs == 1);
    CHECK(secp256k1_memcmp_var(found_output.output.data, output_custom.data, sizeof(output_custom.data)) == 0);
    CHECK(!found_output.found_with_label);

Tested on top of 17242cc with tests.exe 1 on GCC 16.2.0, passes cleanly.

@Yudis-bit: Good idea, applied your patch in the same commit and added you as co-author. I changed the found output equality check to use the xonly-pubkey compare function though (secp256k1_xonly_pubkey_cmp), as I think that's a bit cleaner than comparing the raw bytes of the opaque objects. Also rebased on master, in order to avoid potential CI problems (see #1953).

ACK 93d026ec5e1f50fc7689b5941827013332e4231c.

Using secp256k1_xonly_pubkey_cmp is definitely cleaner than raw byte comparisons. Re-tested locally on Clang 22.1.8, all tests pass. Thanks for adding co-author.