Fix HTTP idempotency result storage and error metric labels #27

Problem

Two real error paths on main at 729132a7010b0fcdf2e70ecadb974e92755ba6d0 can fail while handling an HTTP proxy request:

1. handle_http_proxy initializes cache_config only inside GET/HEAD cache branches, but successful POST/PUT/PATCH requests with an idempotency_key use cache_config when choosing the stored-result TTL. That can raise UnboundLocalError instead of returning and storing the upstream result.
2. The HTTP exception handlers call errors_total.labels(...) without the required tenant label after the unified metric helper has already emitted the same error. Prometheus then raises a label error while ReliAPI is trying to return the upstream/network/internal error response.

The public README and site are being narrowed separately so HTTP idempotency is not presented as a supported beta baseline before these paths are fixed and tested.

Acceptance

• POST, PUT, and PATCH requests with an idempotency key return the first upstream result and store it with an explicit, deterministic TTL.
• a repeated matching request returns the stored result; a mismatched body still returns the existing conflict behavior.
• HTTP status, network, and unexpected exception paths return their intended ErrorResponse without a Prometheus label exception.
• metrics contain the normalized tenant label exactly once per intended metric series.
• focused tests reproduce both defects on the public /v1/proxy/http path and pass in CI.

Non-goals

• No exactly-once or provider-billing guarantee.
• No public reliability or performance claim until a dated end-to-end trace exists.

Tracked from kiku-jw/kikuai-project-map#13.