style: restore import order in dashboard token_auth (unblocks all PRs)

[chenmingwei23]

What is the problem?

main is red. Backend Lint & Type Check fails on both 3.10 and 3.12 with:

ERROR: src/kiro_crew/dashboard/token_auth.py Imports are incorrectly sorted and/or formatted.

In token_auth.py the kiro_crew.dashboard.tailnet import block sits above kiro_crew.dashboard.revocation_gen, which is out of alphabetical order (tailnet > revocation_gen).

Neither contributing PR could have caught this. #2424 merged at 04:49:37Z and added the tailnet block; #2388 merged at 04:55:14Z, six minutes later, and inserted the revocation_gen block — with an explanatory comment between the two — at a position that was correct against its base, where tailnet did not yet exist. Each branch was isort-clean on its own base; only the merged result is unsorted. Git produced no textual conflict because the two insertions do not overlap.

Why this issue matters to the user

Backend Lint & Type Check is a blocking CI job, so every open PR in the repository fails it regardless of that PR's own content — the failure is inherited through the merge ref. Authors see a red check pointing at a file they never touched, and the natural triage steps all mislead: the file is absent from their diff, their local gate is green against their (older) base, and re-running the job reproduces the failure identically because the re-run stays pinned to the same merge ref. The likely outcomes are wasted investigation or, worse, someone concluding the isort gate is unreliable.

How our fix solves it

Move the tailnet import block below revocation_gen, exactly as isort orders it.

Symptom → root cause: the symptom is one file failing an ordering check. The cause is that two non-overlapping insertions into the same import list each satisfied the ordering invariant locally while jointly violating it. The root cause is that import order is a whole-list property, but CI only ever evaluated it against each branch's own base — so a semantic merge conflict of this shape lands green and is discovered only by the next PR to inherit it.

The change is the exact output of isort src/kiro_crew/dashboard/token_auth.py with the repo's pinned isort==6.0.0 — 7 lines moved, no import added, removed, or renamed. The comment explaining the revocation_gen re-export stays attached to that block; the # noqa: F401 # re-exports pragma is untouched.

What tests we did

• isort --check-only src/kiro_crew test — reproduced the failure on a clean main checkout at 584bbb05f before the change, and confirmed clean after. This is the same command the failing CI job runs, at the version pinned in pyproject.toml.
• flake8 src/kiro_crew test and mypy src/kiro_crew/ (862 files) clean, confirming the reorder does not disturb the F401 re-export pragma or the import-cycle structure the comments describe.
• No test is added. The change moves no logic and the reordered names are re-exports whose behavior is already covered; a test asserting import order would be asserting isort's own output. The genuine coverage gap is in CI, not in the suite — see below.

Manual verification: N/A — the change is mechanical formatter output, verified by the formatter itself.

Any other suggestions on the work

This will happen again. The gap is that lint runs against each branch's base, so a pair of independently-clean insertions into one sorted list can only be caught after the fact. Two options worth considering, neither in scope here:

1. Run the lint gate on the merge ref rather than the branch head, so a PR is judged against what it would actually produce on main.
2. Add a post-merge lint job on main so the breakage is reported against the commit that caused it, instead of surfacing on an unrelated PR minutes later.

I can file that as a follow-up issue if it is worth tracking.

[github-actions]

GPT 5.6 Review — ✅ no blocking findings

GPT 5.6 completed its review of 06d5136171ca97e2719e9b3a389ff878c43666a5 and found no blocking issues.

This comment is updated in place on each push.

Review details

No findings.
[GPT-REVIEWED] 06d5136

False positive or not applicable? A repository writer can comment:
/ai-review override gpt 06d5136171ca97e2719e9b3a389ff878c43666a5: <one-sentence reason>

[github-actions]

Opus 4.8 Review — ✅ no blocking findings

Reviewed 06d5136171ca97e2719e9b3a389ff878c43666a5 — this comment is updated in place on each push.

Review details

The diff is a pure import-block reorder (isort output), moving the tailnet import block below revocation_gen. No logic, no added/removed/renamed imports, and the F401 re-export pragma and explanatory comment are untouched. Nothing semantic to catch here.

No findings.

[OPUS-REVIEWED] 06d5136

Verdict parsed from the review's SHA-scoped output markers for commit 06d5136171ca97e2719e9b3a389ff878c43666a5.

False positive or not applicable? A repository writer can comment:
/ai-review override fable 06d5136171ca97e2719e9b3a389ff878c43666a5: <one-sentence reason>

[github-actions]

Design Review (Fable 5) — ✅ PASS

Advisory design-level review of 06d5136171ca97e2719e9b3a389ff878c43666a5 — updated in place on each push; does not block merge.

Design-Verdict: PASS

Mechanical isort output restoring alphabetical order broken by a semantic merge of two independently-clean PRs; unblocks a red main, diff matches description exactly.

[DESIGN-REVIEWED] 06d5136

[chenmingwei23]

Note on overlap: the same 7-line reorder is now also carried in #2476, so that PR can reach green without waiting on this one.

This PR stays open on purpose — it unblocks every other open PR in the repo, and a 7-line formatter reorder can land far faster than a feature PR under review. Whichever merges first makes the other's hunk a no-op; it is pure isort==6.0.0 output, so the two cannot diverge.