[P1][Plan 5] SF-019 — Split the monolithic client component into route and feature modules

[Ankit6149]

Confirmed problem

Landing, Studio workflow, source ingestion, generation, review, exports, library, connections, sessions, OAuth, settings, and publishing are coupled inside one large client component and shared state graph. This coupling contributes directly to stale state, export divergence, and navigation bugs.

Scope

• Separate landing, /studio, /library, /connections, and /settings route components.
• Keep campaign state inside a Studio domain provider/store.
• Extract platform/provider/status metadata into dedicated modules.
• Create small presentational components with explicit props and no hidden network calls.
• Move API/persistence/export behavior behind testable services.

Acceptance criteria

• The main page no longer contains the full application.
• Route components can render independently from fixtures.
• Campaign state does not leak into unrelated landing/settings surfaces.
• Network calls are owned by explicit hooks/services.
• Existing save, restore, generation, review, and publishing guards continue to work.

Required verification

• Component tests for every route and major Studio stage.
• Reducer/service integration tests.
• Navigation and restore tests across routes.
• Full frontend tests and production build.

Dependency

Begin only after Plans 1–3 contracts are stable enough to avoid moving broken ad hoc state unchanged.