Browser Private 2PC mode ignores High and runs reveal-based forward

[blacks1ne]

Summary

The browser UI presents the two-server mode as “Private 2PC” and sends security = High, but the server currently ignores that requested security level and executes the reveal-based Q16 forward path.

Evidence

• web/src/App.tsx renders the green Private 2PC badge.
• web/src/hooks/usePrivateChat.ts writes security = High into SessionInit.
• crates/klearu-server/src/bin/server_a.rs parses the byte into _security and does not use it.
• server_a.rs and server_b.rs call server_forward_shared_reveal_*_q16.
• crates/klearu-server/src/two_party.rs documents that this optimized path reconstructs the plaintext embedding and performs plaintext forward on both servers.

The DPF layer still hides token IDs at the PIR boundary, but the current label implies a stronger end-to-end property than the executed path provides.

Proposed resolution

Either:

1. wire High to the actual no-reveal/Ferret-backed protocol; or
2. rename the browser mode to something precise, such as “two-server DPF token privacy (reveal-mode prototype).”

Unsupported security levels should be rejected rather than silently ignored. The README's lower-security description should also be aligned with private_pipeline.rs, which describes that mode as having no input privacy after the embedding boundary.

Acceptance criteria

• The requested security mode controls the protocol that runs, or the server rejects it.
• UI and documentation state the actual privacy boundary.
• A protocol-selection test verifies that High cannot silently enter a reveal path.