fix(gst): the API search path constructs and submits a portal route

[lamemustafa]

What

submitPortalGstr3bForm in src/connectors/gst/filed-returns-api-search.ts builds a form, sets action = "/returns/auth/gstr3b", and submits it — after writing several portal preference keys into localStorage.

That is constructed portal navigation. AGENTS.md prohibits it without qualification:

Construct a portal URL to navigate. Click the portal's own control. One exception, and only one: opening the portal's public landing page in a new tab, in direct response to an explicit user action. Everything else is prohibited whether or not a session is active … Two constructed in-flow navigations were WAF-rejected and one ended a live session.

Status

Pre-existing, not introduced by any recent PR. This path predates #304 and ships in the published package. #304 removed it — correctly, on this count — but removed the acquisition path with it and broke filed-return selection entirely (#306), so it was reverted in #307. The revert restores this violation along with the working path.

So the current state is: Pack works, and the way it works includes a prohibited navigation that has previously ended a live session.

What it needs

The portal renders its own control for this transition; use it. That is the whole rule — the prohibition exists because the constructed route is what the WAF rejects.

Removing it is not optional, but removing it without a working replacement is what #304 did. The replacement has to be validated by a live authenticated run before it merges, not after.

Priority

High. This is a session-ending risk for a user in the middle of a compliance download, and the failure would look to them like the portal logging them out for no reason.

Related: #306 (why #304 was reverted), #307 (the revert).

[lamemustafa]

Blocked on one live observation. Recording why, so the next attempt does not restart from scratch.

The fix is not a substitution

The obvious repair — reuse the compliant helper that clicks the portal's own control on a result row — does not apply. That helper takes a rendered DOM row. The API path never has one: it receives a JSON row, derives values from it, writes portal storage, and submits the constructed form. There is no row to click, so the call cannot be swapped.

That makes the plausible shape "use the API result to decide, and navigate only through the portal's own rendered row" — the API becomes a lookup, and all navigation goes through the existing compliant path.

What that shape depends on

An unestablished fact: after the portal's own Search action, does a result row expose exactly one visible, scope-bound control that reaches the filed return, consistently across periods?

If yes, the constructed form can be deleted outright. If no, it cannot, and this issue stays open with the risk documented rather than traded for a different violation.

Per AGENTS.md — capture live evidence before writing a spec for portal behaviour. Three specs in one session were written from a plausible mechanism and each was falsified by the next probe. This is the fourth such mechanism and it will not be written from inference.

Next step

A manual, read-only observation in an authenticated session, reported de-fanged (control labels and behaviour only; no HTML, URLs, identifiers, or screenshots), then recorded in docs/PORTAL_INTEGRATION_FINDINGS.md before any code is written.