Replace panic in HpkeError secp256k1 conversion with safe error handling

[chavic]

Converting Hpke errors can panic if new secp256k1::Error variants appear.

Todo:

• Add a safe catch‑all in the conversion layer.
• Ensure unknown variants map to a stable “Other/Unknown” error.
• Add a test to verify no panic on unexpected error values.

[Mshehu5]

Hey Chavic can i handle this

If yes can I clarify somethings

1. I checked the FFI layer and didn't find HPKE used directly it only wraps the main library EncapsulationError which leads to payjoin/src/core/hpke.rs where the panic is also located for From<secp256k1::Error> for HpkeError is this the "conversion layer" the issue refers to? or should changes be made elsewhere?
2. For the catch-all error format should I use:
   Display ({}) -> "secp256k1 error: malformed or out-of-range secret key"
   Debug ({:?}) -> "secp256k1 error: InvalidSecretKey"
   Which is preferred for FFI consumers?

[chavic]

For the first question, yes, payjoin/src/core/hpke.rs implements Fromsecp256k1::Error for HpkeError and panics for variants other than InvalidPublicKey.

We want to replace the panic with a non-panicking mapping strategy:

• introduce HpkeError::Secp256k1(secp256k1::Error) or HpkeError::Secp256k1Unknown(String)
• or map all non-InvalidPublicKey variants to a safe generic variant.

So the result is that no code path can panic due to unexpected secp256k1::Error variants. And the unit test should cover at least one non-InvalidPublicKey variant mapping (as feasible).

For the second question, Display ({}) -> "secp256k1 error: malformed or out-of-range secret key" is prefered.