045ba6975f
Wires the auto_approve_requests user flag into the request creation flow. When the flag is set (admin enabled it via /admin/users from U2-T3), POST /api/requests transitions the just-created pending row through Service.Approve inline, which dispatches to Lidarr the same way a manual admin approve does. Failures inside Approve (ErrLidarrDisabled, ErrDefaultsIncomplete, network/Lidarr errors) leave the row pending — same fallback as manual approve hitting the same path. The user gets a 201 either way; admin can still resolve the row in /admin/requests if it stayed pending. The handler logs the auto-approve failure with user_id + request_id for observability. The "actor" id passed to Approve is the user's own ID — they're acting under the privilege the admin granted them via the toggle. The trail of "admin set the flag" already lives in audit_log (ActionAutoApproveToggle from U2-T2). Adding a per-auto-approval audit entry is a future enhancement; for v1 the toggle audit plus the request row's status transition is enough. Test verifies the Lidarr-disabled fallback contract: a user with auto_approve=true and Lidarr unavailable still gets 201 Created with status=pending (no crash, no 500). The "auto-approve actually succeeds" test path requires a Lidarr stub; deferred until a broader Lidarr test fixture lands.