ci(contracts): make verify-contract-addresses check explicitly blocking

[Onyii1234]

Summary

• Added concurrency group (verify-contracts-${{ github.ref }} with cancel-in-progress: true) so a new push cancels any stale in-progress run on the same PR, preventing an outdated result from gating a merge.
• Set continue-on-error: false explicitly on the verify job. The default is already false, but stating it makes the blocking intent unambiguous to anyone reading or editing the file.
• Added timeout-minutes: 15 so a hung Stellar CLI fetch cannot block the queue indefinitely.
• Added inline comments explaining why the job is blocking and where the retry logic lives (inside the script, not at the step level).

The script itself (scripts/verify-contract-addresses.ts) already satisfies all three acceptance criteria from #389 and #431: it runs pnpm verify:contracts on PRs touching constants.ts/known-pools.ts, exits non-zero on any hash mismatch, and retries the on-chain fetch up to three times on transient RPC failures. This PR makes the job's blocking nature explicit and adds the concurrency guard that was missing.

Test plan

• pnpm lint && pnpm typecheck && pnpm test pass locally
• Workflow YAML is valid: gh workflow view verify-contract-addresses lists the job after merge
• Confirmed continue-on-error: false and concurrency group are present in the updated file

Closes #431

[vercel]

@Onyii1234 is attempting to deploy a commit to the Collins' projects Team on Vercel.

A member of the Team first needs to authorize it.

[Onyii1234]

i have created a seperate pr as you suggested sir please merge please

[collinsezedike]

Good catch flagging that branch protection needed to actually require this check, that gap turned out to apply repo-wide, not just here. Configured branch protection directly to require the six checks that always run on every PR: Lint & Typecheck, Test, Commit Messages, PR Title, Soroban Contract Tests, Dependency Review.

Deliberately did not add "Verify On-Chain Bytecode" itself to the required list, since it's path-filtered and only triggers on PRs touching constants.ts/known-pools.ts. Marking a conditionally-triggered check as required would permanently block merging on every PR that doesn't touch those files, since the check never reports at all for them. continue-on-error: false already makes it blocking when it does run, which is the correct behavior for a conditional check.

The concurrency guard, timeout, and comments here are all genuinely useful additions.

Thank you for the contribution. Feel free to grab another open issue.

Merging now.