test(api): HTTP integration tests for pending-operations endpoints (#81)

[thomasluizon]

Summary

Adds PendingOperationsControllerTests driving the full agent confirmation flow over real HTTP against Postgres (orbit_test): POST /api/ai/pending-operations/{id}/confirm -> /step-up -> /step-up/verify -> /execute, anchored on the api_keys.manage (StepUp) capability so every gate is exercised.

What it covers

• confirm — 200 + token persisted (ConfirmedAtUtc/ConfirmationTokenHash in DB); unknown id -> 404.
• step-up — challenge issued (200, code captured via the email fake); immediate second request -> 400 service cooldown (60s).
• step-up/verify — valid code sets StepUpSatisfiedAtUtc; invalid code -> 400; repeated verifies trip the auth rate limiter (429).
• execute — confirm-only (no step-up) -> 200 body Status=PendingConfirmation, PolicyReason=step_up_required; full confirm+step-up path -> Succeeded (creates a real API key); unknown id -> 404.

Seam added

IntegrationTestWebApplicationFactory registers a capturing IEmailService (CapturingEmailService) via ConfigureTestServices, exposing LastVerificationCode so the emailed-only step-up code is readable. Mirrors TestEmailService in AgentStepUpServiceTests. The existing JWT UseSetting is preserved (added to, not clobbered).

Notes

• Stacked on chore(api): fix integration-test Jwt:SecretKey length (>=32 bytes) #176 (the integration-test Jwt:SecretKey length fix). Base is chore/fix-integration-jwt-secret, NOT main. Merge chore(api): fix integration-test Jwt:SecretKey length (>=32 bytes) #176 first.
• build is clean (full solution: 0 errors). Locally all 10 tests pass against a Postgres-backed orbit_test; CI does not run Orbit.IntegrationTests, so they need a Postgres-backed env (local/user machine) to execute.
• One implementation note: ArgumentsJson is a jsonb column, so the seed normalizes args through Postgres before computing the operation fingerprint — otherwise jsonb key-reordering breaks the execute-time fingerprint match.

Refs thomasluizon/orbit-ui-mobile#81

🤖 Generated with Claude Code

[claude]

One correctness bug: StepUpVerify_ExceedsAuthRateLimit_ReturnsTooManyRequests exhausts _userId's auth rate-limit quota (5 req/min, partitioned per-user in DistributedRateLimitAttribute), so Execute_AfterConfirmAndStepUp_Succeeds — which calls the same verify endpoint as the same user immediately after — will receive 429 instead of 200 whenever both tests land in the same clock-minute window. Detailed on the inline comment. Fix: give the rate-limit test its own user account so the exhausted bucket is isolated.

[claude]

Solid integration test suite for the pending-operations flow. The full confirm → step-up → step-up/verify → execute path is exercised end-to-end against a real DB, all gates (cooldown, invalid code, missing step-up, rate limit) are covered, and the rate-limit case is correctly isolated to its own user to prevent bleed across tests. The CapturingEmailService seam is cleanly wired via ConfigureTestServices / RemoveAll, and the JSONB-normalization trick in NormalizeToJsonb correctly handles the key-reordering that would otherwise break fingerprint matching at execute time. No correctness, security, or contract issues found.