fix(sign): fetch G2 Developer ID intermediate (the actual one our cert uses)

[gok03]

Root cause of the lingering notary rejection

Apple issues Developer ID certs from one of two intermediates:

Generation	Subject	URL
G1 (legacy)	`CN=Developer ID Certification Authority, OU=Apple Certification Authority`	`DeveloperIDCA.cer`
G2 (current, ~2018+)	`CN=Developer ID Certification Authority, OU=G2`	`DeveloperIDG2CA.cer`

PR #22 only fetched the G1 cert. Our actual leaf is issued by G2 (issuer line: `OU=G2`), so the embedded chain still couldn't be verified by Apple's notary and submissions kept getting rejected with:

"The binary is not signed with a valid Developer ID certificate."

Fix

Fetch both intermediates and embed both. `rcodesign sign` accepts `--certificate-der-file` multiple times, and Apple's notary picks the matching chain. Future-proofs against rotation.

Also: while debugging, I found the previous `MACOS_SIGN_P12` secret was the wrong identity — it had an Apple Development cert, not the Developer ID Application cert. The user re-exported the correct `.p12` and updated the secret out-of-band.

Verified locally

Ran the script end-to-end against the corrected `.p12` on local hardware. Apple's own `codesign` reports the right chain:

```
Authority=Developer ID Application: Gokulavasan Murali (837VZFQ23B)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
TeamIdentifier=837VZFQ23B
flags=0x10000(runtime)
```

Test plan

• CI green on this PR
• Merge → release-please opens v1.2.3 PR
• Merge v1.2.3 → release.yaml runs:
  • `sign-macos: fetching ... intermediates (G1 + G2)` in log
  • Notarize step completes without the "invalid Developer ID certificate" error
• `brew install refusehq/tap/refuse` on a clean Mac — no Gatekeeper dialog
• `spctl --assess --type execute --verbose $(brew --prefix)/bin/refuse` shows `source=Notarized Developer ID`