Portal (#6391)

# Description of Changes

## What & why

This PR introduces the **Stirling developer portal** — a new
control-plane frontend that sits alongside the existing PDF editor —
plus the shared design system and workspace structure needed to host
both apps in one frontend.

The portal is the parent product surface: where users connect sources,
compose pipelines, wire agents, and manage usage / billing /
infrastructure, with the PDF editor as one capability inside it. This PR
lays the **foundation** — workspace reshape, design system, app shell,
navigation, and a mock-driven home — rather than wiring real backends
(those surfaces are placeholders for follow-up phases).

## What's in this PR

**1. Frontend repo reshape (`frontend/src/` → `frontend/editor/`)**
The existing editor app moved under `frontend/editor/`, so `editor`,
`portal`, and `shared` are siblings in one workspace. All references
were updated accordingly: `LICENSE`, `.dockerignore`, `.gitignore`,
build/sign shell scripts, the GH language-check script, the Taskfile,
and Docker config. **No editor source logic changed — path references
only.**

**2. New shared design system (`frontend/shared/`)**
- **Design tokens** in `tokens.css` as the single runtime source of
truth (light/dark, category accents, gradients). `tokens.ts` now holds
only the `Tier` type — the old JS palette mirror was removed (nothing
consumed it and it had drifted).
- ~30 framework-light **components** (Card, Button, Input, Select, Tabs,
Modal, Drawer, Toast, MetricCard, StatusBadge, Skeleton, EmptyState, …)
with Storybook stories.
- **Typed data catalogues**: `endpoints.ts` (10 verticals / 64
endpoints) and `ops.ts`.

**3. New developer portal app (`frontend/portal/`)**
- App shell: `Header`, `Sidebar`, `AssistantPanel`, search modal,
notifications, tier switcher, theme toggle, MSW toggle.
- **Tier-aware** home (free / pay-as-you-go / enterprise): KPI strip,
30-day usage chart, onboarding checklist, quick actions, recent
activity, region health, product grid, and a curated **"Popular use
cases"** teaser.
- **Documents** view hosting the full, tab-filterable endpoint
catalogue.
- Placeholder views for Sources / Pipelines / Agents / Editor /
Infrastructure / Usage & Billing / Developer Docs / Settings (follow-up
phases).
- **MSW-mocked** API layer: `api/*` issues real `fetch`, intercepted by
mocks in dev/Storybook; pointing at a real backend is just a matter of
not registering MSW. `react-router` URLs; Tier / View / UI contexts.

**4. Tooling & guardrails**
- ESLint extended to `portal` + `shared`, with **layering-boundary
rules**: `shared/` may depend only on third-party packages and itself
(no `@app` / `@portal` / `@core` / `@proprietary` / Tauri), so it stays
cleanly extractable into a standalone package later.
- `dpdm` circular-dependency check now walks editor + portal + shared
(the old glob matched only 2 files).
- New **devDependencies only** — Storybook (+ a11y/docs/themes addons),
MSW. No runtime dependencies added.
- New tasks: `frontend:dev:portal`, `frontend:build:portal`.

## Testing done locally

- `tsc` for both `portal` and `shared` projects — clean
- `eslint --max-warnings=0` across the whole frontend — clean
- `dpdm` circular-dependency check — no cycles
- Editor builds clean: `vite build editor --mode core` (✓ built, only
the pre-existing >500 kB chunk-size advisory)
- Editor runs in dev (core mode) with **zero console errors**; portal
runs in dev across all three tiers

## Notes for reviewers

- The change is overwhelmingly **additive**: `shared/` and `portal/` are
brand-new; the existing editor is path-reference changes only.
- The portal is intentionally **mock-driven** at this stage — real
backends and the remaining views land in follow-up phases.

---

## Checklist

### General

- [ ] I have read the [Contribution
Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md)
- [ ] I have read the [Stirling-PDF Developer
Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md)
(if applicable)
- [ ] I have read the [How to add new languages to
Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md)
(if applicable)
- [x] I have performed a self-review of my own code
- [x] My changes generate no new warnings

### Documentation

- [ ] I have updated relevant docs on [Stirling-PDF's doc
repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/)
(if functionality has heavily changed)
- [ ] I have read the section [Add New Translation
Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags)
(for new translation tags only)

### Translations (if applicable)

- [ ] I ran
[`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md)

### UI Changes (if applicable)

- [ ] Screenshots or videos demonstrating the UI changes are attached
(e.g., as comments or direct attachments in the PR)

### Testing (if applicable)

- [ ] I have run `task check` to verify linters, typechecks, and tests
pass
- [x] I have tested my changes locally. Refer to the [Testing
Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing)
for more details.

---------

Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>

frontend/portal/src/hooks/useAsync.ts

@@ -0,0 +1,97 @@
+import { useEffect, useMemo, useState } from "react";
+
+export interface AsyncState<T> {
+  data: T | null;
+  loading: boolean;
+  error: Error | null;
+}
+
+/**
+ * Derived render flags for a panel backed by {@link useAsync}.
+ *
+ * Every async-driven section in the portal renders the same three-state shape:
+ *
+ *   - `isLoading` — first load, no data yet → render skeletons
+ *   - `isEmpty` — fetch failed OR data is genuinely empty → render <EmptyState>
+ *   - ready (neither flag set) — data is present → render the real UI
+ *
+ * Error and empty collapse into one branch on purpose: when there's no
+ * backend yet, fetch failures should surface as an empty page rather than
+ * an alarming error banner. The section header always renders regardless of
+ * which branch is active.
+ *
+ * The `ready` state is intentionally NOT exposed as a flag — callers should
+ * gate the ready branch on the actual data (`{events && events.length > 0
+ * && …}`) so TypeScript can narrow `events` from `T[] | null` to `T[]`.
+ */
+export interface SectionFlags {
+  isLoading: boolean;
+  isEmpty: boolean;
+}
+
+export function deriveSectionFlags<T>(state: AsyncState<T>): SectionFlags {
+  const { data, loading, error } = state;
+  const dataIsEmpty =
+    data === null || (Array.isArray(data) && data.length === 0);
+  return {
+    isLoading: loading && data === null,
+    isEmpty: !loading && (error !== null || dataIsEmpty),
+  };
+}
+
+/** Memoised variant for use inside components. */
+export function useSectionFlags<T>(state: AsyncState<T>): SectionFlags {
+  return useMemo(() => deriveSectionFlags(state), [state]);
+}
+
+/**
+ * Lightweight loading-state hook for async functions. Cancels the in-flight
+ * effect on unmount and on dependency change, so race conditions don't
+ * resolve into stale state.
+ *
+ * Intentionally minimal — when we want caching, retries, and revalidation
+ * we'll move this to TanStack Query or similar. For mocked data with sub-
+ * second latency, this is enough.
+ *
+ * @example
+ *   const { data, loading } = useAsync(() => fetchDeployedPipelines(), []);
+ *   if (loading) return <Spinner />;
+ *   if (!data) return null;
+ */
+export function useAsync<T>(
+  fn: (signal: AbortSignal) => Promise<T>,
+  deps: ReadonlyArray<unknown>,
+): AsyncState<T> {
+  const [state, setState] = useState<AsyncState<T>>({
+    data: null,
+    loading: true,
+    error: null,
+  });
+
+  useEffect(() => {
+    const controller = new AbortController();
+    let cancelled = false;
+
+    setState((prev) => ({ ...prev, loading: true, error: null }));
+
+    fn(controller.signal)
+      .then((data) => {
+        if (cancelled) return;
+        setState({ data, loading: false, error: null });
+      })
+      .catch((error: unknown) => {
+        if (cancelled || controller.signal.aborted) return;
+        const err = error instanceof Error ? error : new Error(String(error));
+        setState({ data: null, loading: false, error: err });
+      });
+
+    return () => {
+      cancelled = true;
+      controller.abort();
+    };
+    // Callers own the dependency array — `fn` is intentionally not listed
+    // here so the effect only re-runs when the caller asks it to.
+  }, deps);
+
+  return state;
+}