fix(ui): map Drafts tab correctly and reuse it for gd

[Brams-s]

Why

The default folders.tab_order includes Drafts, but activeFolder() did not map the visible Drafts label to Folders.Drafts. It therefore fell through to Inbox while the UI still highlighted Drafts. The separate gd path opened Drafts as an off-tab folder, producing two Drafts views with different contents.

The same symptom was reported in #6. PR #19 also noticed the missing mapping, but its broader per-account folder changes were closed without merging.

Regardless of whether a custom configuration shows Drafts as a normal tab, every label accepted by TabLabels() needs to resolve to its configured mailbox. This keeps the existing off-tab behavior for configurations that hide Drafts.

What changed

• map the visible Drafts tab to Folders.Drafts
• make gd reuse the normal Drafts tab when present
• retain the off-tab gd fallback when a custom tab order hides Drafts
• clear stale server-search state when gd leaves Search
• add focused regression tests and align the invariant and FAQ documentation

Test plan

• go test ./internal/ui -run 'TestActiveFolderMapsDraftsTab|TestGoToDrafts(ReusesVisibleTab|UsesOffTabFallbackWhenHidden)'
• go vet ./...
• go test ./...
• manually verified with a Gmail IMAP account that the visible Drafts tab loads the configured mailbox and gd does not create a duplicate tab

Refs #6 and #19.

[Brams-s]

Hi, I’ve rebased this onto the latest main and resolved the conflicts. The relevant tests and go vet pass locally. This fixes the Drafts tab folder mapping and keeps Drafts navigation state consistent. When you have a moment, I’d appreciate a review.

[Brams-s]

Same process note as #27: this PR's CI has never actually run.

The workflow run for the current head f34e691 is sitting at action_required — the first-time-contributor approval gate — since 2026-08-31:
https://github.com/ssp-data/neomd/actions/runs/33436155764

That is why the PR shows as UNSTABLE with "no checks reported" rather than green. main has not moved since 2026-08-31, so the branch is still cleanly rebased and the run should be valid as-is.

Could a maintainer approve that run so the PR gets a real upstream result? Happy to rebase first if you would prefer a fresh branch.