fix(escrow): align Soroban invocations with mergefi-contracts + PR-opened webhook (#157, #158, #161, #168)

[Jaydbrown]

Resolves #157
Resolves #158
Resolves #161
Resolves #168

What

Aligns EscrowService / SorobanClientService with the real mergefi-contracts interface (contracts/escrow/src/lib.rs), and makes GithubWebhooksService react to a PR being opened.

#158 — fund() sends the real escrow::fund payload

fund() invoked ('fund', [funderAddress, uuidReferenceId, amount]) — three args, no token, no deadline, and a Postgres UUID where the contract wants a u64 issue_id. It now submits fund(issue_id: u64, sponsor: Address, token: Address, amount: i128, deadline: u64):

• issue_id — the linked GitHub issue id for bounties (threaded through from BountiesService.fund), or a deterministic FNV‑1a‑64 hash of the parent UUID for milestone / maintenance-pool escrows (which belong on the sibling contracts — see EscrowService never passes contractId to soroban.invoke() — maintenancePoolContractId is completely dead configuration #157). Persisted on the new Escrow.onChainId column so release/refund reuse the exact key fund created.
• token — resolved from Escrow.asset via new stellar.assetContractIds config.
• deadline — the bounty/milestone's own deadline, else now + ESCROW_DEADLINE_SECONDS (default 90d). Persisted on Escrow.deadline.

New migration 1784800000000-AddEscrowOnChainIdAndDeadline (both columns nullable, no backfill — prior rows dry-ran).

#161 — release / splitRelease converge on one entrypoint

The deployed contract has no split_release; team splits and single-recipient payouts both go through release(issue_id, recipients: Vec<(Address, u32)>). Both service methods now build an (address, basisPoints) tuple list and call one private invokeRelease(); a lone recipient is the [(addr, 10_000)] case. SorobanClientService.toScVal gained recursive Vec / (Address, u32) tuple encoding. Public /escrow/:id/split-release route and DTOs are unchanged.

#157 — every invocation targets the escrow instance's own contract

EscrowService never passed a contractId to soroban.invoke(), so maintenancePoolContractId was dead. fund() now resolves the deployed contract per escrow (pool deployment for pool escrows, bounty escrow contract otherwise), persists it on Escrow.contractId, and every call — fund/release/splitRelease/releasePartial/poolWithdraw/refund — passes { contractId } through. stellar.maintenancePoolContractId is restored as live config (.env.example, README, configuration.ts).

#168 — bounty moves to IN_REVIEW when a PR is opened

handlePullRequest returned [] for every non-merge action, so markInReview only ever fired synthetically at merge time. Added an opened / reopened branch that resolves each linked issue's bounty and calls markInReview when the PR is actually opened; bounties not in CLAIMED are left untouched.

Incidental

escrow.service.spec.ts had duplicated entities/enums imports and two paymentRepo declarations from an earlier main merge (1b58a30) that fails tsc — collapsed to one set.

Notes

• Branched on top of current main (c0ff5ff), including the poolWithdraw work — poolWithdraw is threaded through the same { contractId } / onChainKeyFor helpers.
• Milestone and maintenance-pool funding still route through the escrow-contract client; moving them to mergefi-milestones / mergefi-maintenance-pool is noted in the README roadmap.
• Tests updated/added across escrow.service, soroban-client.service, github-webhooks.service, bounties.service specs.

[vercel]

@Jaydbrown is attempting to deploy a commit to the chonilius' projects Team on Vercel.

A member of the Team first needs to authorize it.

[drips-wave]

@Jaydbrown Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits