Split oversized AppStore.swift and DeviceDocNormalizer.swift

[tashda]

Summary

Follow-up to #33. The mechanical parts of the code-structure cleanup landed in v1.3.1, but two files remain over the 600-line hard cap because they need design thought rather than a rote extraction:

File	Lines	Why deferred
Shellbee/Core/Store/AppStore.swift	691	Single @Observable class. Splitting needs a domain partition (Devices / Groups / OTA / Notifications / Logs) realized as extension AppStore files. Stored properties have to stay in the main file (@Observable constraint), so the partition is methods-only.
Shellbee/Core/Parsing/DeviceDocNormalizer.swift	646	7 parsing helper types in one file. Some may be small enough to genuinely belong together; needs a read-through to confirm what's worth extracting and what reads better adjacent.

Plan for AppStore

1. Read apply(_ event:) end to end (currently ~227 lines of switch). Identify per-domain handler clusters.
2. Split methods into:
   • AppStore+Events.swift — the per-event handlers extracted from the giant apply switch.
   • AppStore+Notifications.swift — popNotification, popFastTrackNotification, enqueueNotification, notification(...), stripped(...).
   • AppStore+OTA.swift — otaStatus(for:), startOTAUpdate, startOTACheck, startOTASchedule, cancelOTASchedule.
   • AppStore+Logs.swift — clearLogs, insertLogEntry, insertRawLogEntry.
   • AppStore+Devices.swift — device(named:), state(for:), isAvailable, optimisticRename, revertOptimisticRename, recordFirstSeen, removeFirstSeen.
3. Keep stored properties + init + reset + apply dispatcher in the main file.
4. Verify with the seeder mock + UI tests; the surface area is wide enough that visual review isn't enough.

Plan for DeviceDocNormalizer

1. Read end to end. List the 7 types and their dependencies on each other.
2. If any 3+ are tightly coupled (one calls into another and they're never used independently), keep them together in a sub-file.
3. Otherwise split into one type per file under Core/Parsing/Normalizer/.
4. Verify with the doc-parsing tests.

Acceptance criteria

• Both files at or under 600 lines.
• No regression in seeder-driven flows (notifications, OTA, logs, device events).
• No regression in doc parsing — ShellbeeTests/Unit/DeviceDocNormalizer* (if present) still passes.

Notes

Lower priority than #33 because nothing in the codebase is blocked by these files being big — the rule violation is the only forcing function. Pick this up alongside other v2.0 / late-v1.x cleanup work, not before.

[tashda]

Done in 2 commits on `dev` (`2088ebe`, `b34dc27`), folded into PR #35.

AppStore split

`AppStore.swift`: 691 → 116 lines (stored properties, init, reset, first-seen persistence). Methods moved to five domain extensions:

File	Lines	Holds
`AppStore+Events.swift`	275	`apply(_ event:)` dispatcher and the static `logEntry(from:)` / `notification(from:)` helpers
`AppStore+OTA.swift`	140	`activeOTAUpdates`, `otaStatus(for:)`, start/cancel methods, `handleOTAState` / `handleOTAResponse` / `handleOTACheckResponse`, `flashCheckResult`
`AppStore+Notifications.swift`	109	`pop` / `popFastTrack` / `enqueueOTABulkSummary` / `enqueueNotification` / `notification(for:)` / `stripped`
`AppStore+Devices.swift`	49	`device(named:)`, `state(for:)`, `isAvailable`, `optimisticRename` / `revertOptimisticRename`
`AppStore+Logs.swift`	22	`clearLogs`, `insertLogEntry`, `insertRawLogEntry`

Stored properties stay in the main class (an `@Observable` constraint). Formerly-`private` members called across files (`pendingRenames`, `recordFirstSeen`, `removeFirstSeen`, OTA handlers, etc.) bumped to internal — no external API change since they were already module-internal.

DeviceDocNormalizer split

`DeviceDocNormalizer.swift`: 646 → 361 lines (enum entry point, main orchestrator, shared span/section helpers, capability extraction). DTOs and pairing-specific logic moved out:

File	Lines	Holds
`DeviceDocumentationModels.swift`	119	The six tightly-coupled DTOs — `DeviceDocumentation`, `NormalizedDeviceDoc`, `DeviceDocIdentity`, `DevicePairingGuide`, `DevicePairingMethod`, `DeviceDocCapability`
`DeviceDocNormalizer+Pairing.swift`	175	`extractFromNotes`, `makePairingGuide`, `collectStepItems`, `isPureStepList`, `collectSubsections`, `defaultPairingSummary`, prerequisite / success / troubleshooting keyword arrays

Per the Code-structure rule, DTO bundles are explicitly allowed to stay grouped — keeping the six docs models together rather than fragmenting into six files.

Acceptance criteria

• Both files at or under 600 lines (now: AppStore 116, normalizer 361 — both under the 400 soft cap).
• Build green via `xcodebuild` after each commit.
• Seeder-driven flow regression check — folded into the PR's manual test plan.

Largest remaining files (none over 600 hard cap):
```
538 FanControlCard.swift
521 DocumentationExperienceView.swift
425 DeviceCard.swift
396 FeatureCatalog.swift
389 InAppNotificationBanner.swift
378 PairingGuideExperienceView.swift
373 DocBrowserView.swift
```

Five of those are over the soft cap (400). Worth a follow-up sweep but lower priority — none are flagged by the issue.