research(scope): learn the taxpayer's filing profile instead of guessing deadlines

[lamemustafa]

Why this exists

Pack currently decides which periods to plan by guessing from the calendar. It cannot do better today because it knows nothing about the signed-in taxpayer, so it has to assume a filing profile for everyone.

That assumption has already cost us twice, in opposite directions:

• Assume every period is available once its month ends → Pack plans a period that is not filed, the run stalls, and the reader is told to retry something that cannot succeed. (Found in a live run; fix(scope): the period planner plans periods whose returns are not yet due #285, fix(panel): a not-filed period offers a retry that cannot succeed #286.)
• Assume the latest possible deadline for everyone → Pack refuses periods that are filed and downloadable, through every path including manual selection. (Found reviewing the fix for the first.)

Both are the same mistake: guessing a fact the portal already knows.

What Pack would need to know

None of this is established. Listing it as questions, not answers:

• Filing frequency. Monthly or QRMP? Does it differ per return type? Can it change mid-year, and if so does history keep the old cadence?
• What is actually filed. For a given financial year, which periods have a filed return, per return type? Is there a portal surface that answers this in one place, or only period by period?
• Registration date. A GSTIN registered mid-year has no returns before it existed. Planning those periods is the same defect wearing different clothes.
• Status. Cancelled, suspended, or composition-scheme taxpayers — what does the portal show, and what should Pack plan?
• Return types the taxpayer does not file at all. Not every registration files all three.

How this must be approached

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."

So, in order, and not skipping ahead:

1. Research — what the portal exposes, what is documented, what other tools rely on.
2. Ideate — candidate mechanisms, each stated as a falsifiable claim.
3. Probe — capture from a live authenticated session, across profiles if possible.
4. Record — docs/PORTAL_INTEGRATION_FINDINGS.md, with the captured facts including surrounding decoy content.
5. Only then implement, against fixtures built from the captures.

No implementation PR should open against this issue until step 4 exists.

Constraints that do not move

• A probe reads; it does not construct a portal URL to navigate. Click the portal's own controls.
• Nothing captured goes into this repository, an issue, or a PR: no GSTIN, PAN, ARN, taxpayer name, portal HTML, raw portal URL, or local path. Findings are recorded de-fanged.
• Whatever is learned is scope selection only. It must not become a second source of truth about what was downloaded — chrome.downloads correlation remains the sole completion evidence.
• If the filing profile cannot be determined for a taxpayer, Pack fails toward offering the period and letting the portal answer, not toward hiding it — provided fix(panel): a not-filed period offers a retry that cannot succeed #286 has made a not-filed period a clean outcome rather than a stall.

Relationship to the open work

• fix(scope): the period planner plans periods whose returns are not yet due #285 / fix(gst): defer current-year filed periods #294 — the calendar guess. Interim, and the thing this issue exists to retire.
• fix(panel): a not-filed period offers a retry that cannot succeed #286 — a not-filed period must be a clean skip. Prerequisite. Until it lands, any generous planner turns an unfiled period into a stalled run, which is what forces the conservative guessing in the first place.