fix: investigate stalled auth link navigation in the native app

On the actual native buddy serve app using released Stacks 0.75.299 and STX 0.2.687, the marketing capability link navigated and updated its title, but clicking Sign in from the capability page and Create an account from /login left the URL and page unchanged. No browser errors/warnings appeared. Direct GET/navigation to /login and /register rendered the authored auth pages correctly, including at 320 px without document overflow. No credentials or provider flows were submitted.

Investigate the owning source before choosing a fix. Do not patch node_modules or emitted runtime files. If the cause belongs to STX or Stacks, add a real failing regression there, fix the source and run its native bun run release:patch, then consume and qualify that release in Farming.

Acceptance:

• Reproduce the stalled link activation on a minimal maintained source case and compare the previous published app baseline to distinguish existing behavior from migration regressions.
• Check pointer and keyboard activation, source click interception, route policy, returned response and focus handling for both auth paths.
• Fix the owning source, release it if it is a shared dependency, and consume the frozen published graph without patches.
• Verify capability-to-login and login-to-register navigation on desktop and 320 px, including title, URL, form rendering and browser errors. Do not create accounts or send messages during the check.

This observation is separate from issue #37's cold function-barrel failure. It does not claim a root cause or qualified authentication/provider delivery.

A fresh read-only check of the live deployed baseline successfully followed capability-to-login and login-to-register with pointer activation. At320px, keyboard activation also reached both auth pages with the correct URL, title, form heading and main focus. Both pages had document width320px and no horizontal overflow; no browser warnings/errors or form/provider submissions occurred.

The check used bounded destination waits. Immediate accessibility snapshots can retain the previous document while navigation is still pending, so the original observation alone does not establish a source defect. This live check does not attribute the deployed package versions or replace the frozen-consumer qualification. I will repeat the navigation on the recovered published dependency graph before closing this report.

The separate stale SPA canonical/description issue is still reproducible and remains tracked in stacksjs/stx#2121.

The stalled-link observation is no longer reproducible after waiting for completed navigation, including the actual destination URL and h1 rather than an immediate AX snapshot or the homepage capability h3.

Both the actual deployed release1109922 and a private native ./buddy serve consumer of the frozen Stacks0.75.301/STX0.2.687/BunPress0.2.25 graph pass capability->login->register pointer activation, plus register->login->register keyboardEnter at320px. Correct titles, forms and mainfocus, scrollWidth=clientWidth=320, no browserwarnings/errors. The earlier native299 private check also passes these sequences. No credential/provider/form submission occurred.

No maintained-source navigation defect was demonstrated, so no dependency patch or speculative source release was introduced for this observation. An initial early snapshot/click can precede the prior route's completion; the retained checks now wait for the actualURL+h1. The separate SPAheadmetadata defect remains open inSTX#2121.

Closing this observation as not reproducible in the verified current consumer. Recovery PR#41 is merged and its exact/mainCI and actual deployment pass.