Add safe catch-all for secp256k1::Error conversion in HpkeError

[Mshehu5]

Closes: #1274

Replace panic with a match to Other(String) to handle unknown secp256k1 error variants. This prevents crashes for unknown varients and if new variants are added upstream.

Pull Request Checklist

Please confirm the following before requesting review:

• I have disclosed my use of
  AI
  in the body of this PR.
• I have read CONTRIBUTING.md and rebased my branch to produce hygienic commits.

[coveralls]

Pull Request Test Coverage Report for Build 22723399575

Details

• 15 of 15 (100.0%) changed or added relevant lines in 1 file are covered.
• 4 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.01%) to 82.497%

---

Files with Coverage Reduction	New Missed Lines	%
payjoin/src/core/hpke.rs	4	93.26%

Totals
Change from base Build 22686255615:	0.01%
Covered Lines:	10638
Relevant Lines:	12895

---

💛 - Coveralls

[benalleng]

cACK seems simple enough, not sure if there was another approach in mind but this seems simple enough to catch the unhandled errors

[spacebear21]

I think we should name the variant more explicitly, and keep the inner details opaque.

Suggested change

	Other(String),
	UnexpectedSecp256k1Error,

[DanGould]

What was the rationale for keeping the inner details unrecorded @spacebear21 ? I can understand leaving them opaque, but I think that could be done with a private tuple field rather than choosing to discard. This is pretty minor afaict but would help surface real problems in error logs if they ever were to arise and we should document that the decision was deliberate so we can close the thread on this for 1.0 error stabiliazation https://github.com/DanGould/rust-payjoin/pull/9/changes.

[spacebear21]

HpkeError is only used in opaque Internal error variants, it just seemed like information overload and inelegant to store as a string. I guess an opaque tuple field would be fine

[spacebear21]

ACK c10f534