sec(ri-exchange): auto mode and nil-creator rows bypass 4-eyes; tighten #673 tests #679

Summary

Gaps left by PR #673 (direct-execute refusal under 4-eyes; closes #517), found in its independent review (deployment-investigation-kimi, review at 2aa8f1d). #517 covers the two direct-execute endpoints only.

Current behaviour

A. Auto mode runs unattended. With RIExchangeEnabled and RIExchangeMode == "auto", the scheduler runs exchange.RunAutoExchange (internal/server/handler_ri_exchange.go) and executes exchanges with no approval; RequireDifferentApprover is never consulted. Manual mode only creates pending rows, which go through the approve path.
B. Nil-creator rows are approvable under 4-eyes (pre-existing, #233). requireDifferentRIExchangeApprover (internal/api/handler_ri_exchange.go) returns nil when CreatedByUserID is nil. Automated pending rows therefore can be approved by any approve-any holder, or by an emailed token with no session. Purchases deny NULL creators in this mode (requireDifferentApprover, handler_purchases.go); exchanges deliberately do not.
C. Test gaps in #673. The Azure global-config lookup failure (fail-closed) is untested; the AWS tests do not spy on exchange.ExecuteExchange and rely on 403 vs the no-credentials 500.

Owner questions

1. Should enabling auto mode require 4-eyes to be off (or refuse/downgrade auto to manual while RequireDifferentApprover is on), or is auto an explicit admin opt-in that stays exempt?
2. Should nil-creator exchange rows be approvable under 4-eyes, or denied like purchases (admin disables the mode to approve)?

Expected behaviour

Per the answers: enforce or document each exemption; add the Azure fail-closed test and an explicit "no exchange call" assertion on the AWS path.

References

PR #673, issues #517, #233. Severity: medium (A, needs owner decision), low (B, C).