Release v2.17.5

Summary

An invitation link asked the person to pick an identity provider twice. The first
choice signed them in and returned them to a second, identical selection page;
only the pass after that completed the invitation and reached the application.

A deployment that declares a frontend is routed with a catch-all covering every
path, and that route carries the default RequireAuthenticatedUser policy. It
matched /invite/{token} and /register too, so authorization refused both
before the middleware that owns each flow ever ran. Nothing was staged and no
pending-invitation cookie was set, so the sign-in that followed carried no
capability binding and the invitation could not complete — until a later pass,
by which time the first one had finally planted the cookie it needed.

Fixed

• An invitation link no longer asks for an identity provider a second time after signing in, and completes on the first attempt.
• /invite and /register are answered by the invitation and registration flows in every deployment, instead of being redirected to provider selection wherever a catch-all route covers them.