Distinguish the original Help reason from the driver's current blocker

Reusing a Help endpoint does not imply that its saved step tracks current driver progress. Trace three separate contracts: the original request reason, the progress projection, and the issue resolution trigger. A UI labelled 'Stuck on' can become misleading when backed by a deliberately preserved historical reason; advancing one step and completing the entire form are different resolution policies. Test recovery after the reported blocker as well as final completion before promising automatic resolution.

Evidence/example (2026-09-10): In Shield COR-3968 / PR #795 investigation, GitHub main's web/src/lib/stuck-flows.ts preserves a help_request's original stuckOnPhoto while required photos remain; resolveFlowIssues is a separate driver-done path called by submissions/batch. The new entry_gate display label therefore does not itself provide recovery semantics. This is source-level evidence only: production DB access was unavailable, so no specific incident state or production root cause is asserted.