fix another copyright date that won't pass review, and while we are touching this, improve the name of the context manager function

fix comment

rebase

• more defensive coding for unexpected build status & conclusion (hand success and failure for "status" even if I don't expect these values)
• change GithubActions.get_latest_workflow_status to return both run_id and build_status for a single API call (don't cache the values, query the API for every call)
• Syntactic sugar: use a contextmanager to temporarily change the run_id or build_status in tests

i'm getting the same hash, and the file content seems to match PR1911

replaced by D19550

update the usage example note in README.md

rebase

fix the fuzzer that was backported out of sequence (https://github.com/bitcoin/bitcoin/pull/19379)

it is still missing something, looks like some deprecated functions are used in the node's codebase

apply changes missed in D19510

see D19510

review items

CI link : https://github.com/PiRK/secp256k1/actions/runs/21832357666

fix conflicts (see D19499)

I missed a conflict

maganda sa akin

제 눈에는 좋아 보여요

I'm going to edit the summary and test plan because for some reason I'm not able to make it work anymore for win32 (so i'll remove the claim that we support both)

properly support both win32 and win64 with a single ENV var (WIN_ARCH, defaults to win64)

actually make it work for both win32 and win64, by simply using a wildcard for the platform tag. This way the switch from 64 to 32 bits will require only setting an ENV var WIN_ARCH=win64.

Related CI failure https://build.bitcoinabc.org/buildConfiguration/BitcoinABC_ResourceIntensiveBuilds_BitcoinAbcCrossBuildLinuxAArch64/1059251?buildTab=

https://github.com/PiRK/secp256k1/actions/runs/21674543209

fix env var name (we are still missing the backport that renames this var)

https://github.com/PiRK/secp256k1/actions/runs/21673573915

Plus backporting everything roughly in the same order makes it easier than selecting pieces and omitting others (which causes conflicts when cherry-picking). Here we do create some conflicts by backporting something earlier than we should, but it is because Cirrus is broken and we lost CI coverage.

In D19520#444149, @bytesofman wrote:

re: testplan

push to github, wait for github actions to complete

is this effectively duplicated with our CI, what "goes green" in this diff? Or does this happen at the github mirror?

afaik we don't use Cirrus CI or github actions, so is this really just a maintenance backport to simplify catching up with more secp256k1 things?

otherwise, seems to match the backports mentioned

test MULTISET, remove the corresponding Cirrus job