Split charge response errors by MPP failure layer

[betterclever]

Summary

Fixes #453.

• add typed PaymentError variants for non-402 charge response failures after credential submission
• keep 402 responses classified as PaymentRejected, matching MPP semantics for failed payment credential validation
• classify non-402 4xx responses as application-layer payment response errors, and 5xx responses as server-layer payment response errors

Why

tempo-request previously mapped every charge response with status_code >= 400 to PaymentRejected. MPP uses 402 for payment-required and payment credential validation failures. Other 4xx/5xx responses after credential submission are not necessarily payment rejections; they are response-layer failures from the protected resource/server.

This keeps payment failures distinct from application/server failures while avoiding any claim that non-2xx responses imply successful settlement.

Tests

• cargo fmt
• cargo test -p tempo-request payment::charge::tests::test_parse_payment_rejection -- --nocapture
• cargo test -p tempo-common test_upstream -- --nocapture
• cargo test -p tempo-common -p tempo-request
• cargo check --workspace