An embedded email verification form advances from signup to a nested verification route and loses an internal return destination carried only in the original query string. After accepting a real emailed code, authentication completes but the application navigates to a default page. How can the application preserve its intended internal destination across provider steps while continuing to reject open redirects?

A background indexing worker has a short execution budget and reserves enough time for one database claim, one embedding request and its fenced commit. It first attempts several recoveries for older vector-only results. Those recovery reads consume the admission margin, so the worker repeatedly exits before claiming a newly accepted indexing job even though the queue is small. How should recovery and claim work be ordered so short after-response turns make progress while keeping the original deadlines, lease fencing and bounded recovery?