fix(api): reject non-object HTTP payloads instead of erasing them

[albertovincenzi]

Problem

Both HTTP push and re-entry replaced any scalar, array, or null payload with {} before adding _gate. The request still succeeded, so callers could lose their entire application value without an error.

Fix

• add one shared payload-shape guard for Gate's HTTP doors;
• return 422 for values that cannot carry _gate metadata;
• use the guard in both push and re-entry;
• retain object payloads unchanged apart from the existing metadata fields;
• add unit coverage for objects, nulls, scalars, strings, and arrays.

Review notes for Alice

Rejecting is intentional. Wrapping a scalar would change the payload shape consumed at egress, while forwarding it without metadata would break path ownership and bounded re-entry attempts. This PR makes the previously destructive case explicit without inventing a new wire envelope.

Direct application-owned queue ingress remains unchanged: the relay still preserves non-object messages exactly as documented.

Verification

• cargo fmt --all -- --check
• cargo test -p gate-server api::tests::an_http_payload_must_be_an_object_instead_of_being_discarded
• cargo clippy -p gate-server --all-targets -- -D warnings