chore(release): resolve uuid < 11.1.1 everywhere, SHA-pin CI actions

[syedhassan-aifinpay]

Release-engineering items from the 27 Aug audit that need no decision, done before the next audit.

All 8 open Dependabot alerts were one finding: uuid < 11.1.1 reached transitively via @solana/web3.js → jayson → uuid@8.3.2 in every install root. jayson only calls v4, so the vulnerable v3/v5/v6 path isn't reachable from here — but an alert left open for a known-safe reason teaches people to stop reading the page. Each install root now carries overrides: { uuid: "^11.1.1" }; every lockfile resolves uuid@11.1.1.

Unchanged suites: node 155, wallet 13, mcp 74.

Versions: package.json is published, so the gate requires a bump — @aifinpay/agent rc.3 → rc.4 (rebased onto main after #40 landed as rc.3), @aifinpay/mcp rc.3 → rc.4.

Actions pinned to commit SHAs (tag in trailing comment). Closes the MEDIUM "CI dependencies/actions are not fully immutable".

Targets main because it is the release baseline and carries #42. Nothing here touches settlement code.

[enot3615]

Reviewed. LGTM.

uuid — this is a lockfile bump, and it goes up, not down: 8.3.2 → 11.1.1. 8.3.2 carries npm's deprecation notice ("uuid@10 and below is no longer supported"), so this is the right direction. Checked whether it could matter on the money or crypto path: uuid does not appear in node/src, mcp/src or gate/src at all — it is transitive only, so nothing of ours changes behaviour. The bin path moves (dist/bin/uuid → dist/esm/bin/uuid), which only matters if something shells out to it; nothing does.

mcp rc.3 → rc.4 is required, not cosmetic. @aifinpay/mcp@2.0.0-rc.3 is already published on npm, so republishing that number would fail. Good catch.

The agent bump is the opposite case. @aifinpay/agent has no 2.0.0-rc published — npm latest is 1.8.4 — so node/package.json rc.2 → rc.3 is internal bookkeeping with no public collision.

Version collision with #40

Verified by test-merging both heads: the only conflicting file is node/package.json, where both take rc.2 → rc.3. #40 touches only that file; mcp/package.json and python/pyproject.toml are untouched by it, so merging #40 cannot roll them back — I checked that specifically because the branch tips make it look like it would.

Whoever merges second edits one line: node/package.json → 2.0.0-rc.4. Either order is safe.

One question, not a finding

mcp/package.json depends on @aifinpay/agent: ^1.8.1, and a caret does not cross a major. Once agent 2.0.0 publishes, mcp users will keep resolving to 1.8.x until that range moves.

I checked whether the currently published @aifinpay/mcp@2.0.0-rc.3 is broken by this and it is not — both symbols it imports (AiFinPayAgent, detectFacilitator) exist in the published agent@1.8.4. So this is a coordination question rather than a defect: is mcp 2.0.0 intended to run on the agent 1.8.x line, or does that range need to move with the agent release?