Restructure/frontend editor (#6404)

## Move editor under `frontend/editor/`

Pure restructure: `frontend/` becomes the workspace, `frontend/editor/`
holds
  the PDF editor. 1775 file renames + 40 wiring edits. No logic changes.

  ### Why

`frontend/` is currently the editor — its `src/`, `public/`,
`src-tauri/`,
  config files all sit at the root. Promoting `frontend/` to a
workspace and putting the editor in a sibling folder leaves room for
future
apps to drop in alongside it, sharing one `package.json` /
`node_modules` /
  lint config / Storybook.

  ### What moves

  frontend/
  ├── editor/                ← NEW: everything editor-specific
  │   ├── src/               ← was frontend/src/
  │   ├── public/            ← was frontend/public/
  │   ├── src-tauri/         ← was frontend/src-tauri/
│ ├── index.html, vite.config.ts, vitest.config.ts, playwright.config.ts
  │   ├── tsconfig*.json, tailwind.config.js, postcss.config.js
  │   ├── scripts/
  │   ├── .env, .env.desktop, .env.saas
  │   └── DeveloperGuide.md
├── package.json, package-lock.json, node_modules/ ← workspace install
  ├── eslint.config.mjs, .prettierrc, .prettierignore ← shared tooling
  ├── .gitignore
  └── README.md

  ### Wiring edits (40 files)

  - `.taskfiles/frontend.yml`, `desktop.yml`, `e2e.yml`
  - `build.gradle`, `app/core/build.gradle`
- `eslint.config.mjs`, `frontend/package.json`, `.gitignore`,
`.prettierignore`
  - `docker/frontend/Dockerfile`
  - 8 `.github/workflows/*.yml`, plus `.github/dependabot.yml`,
    `.github/config/.files.yaml`, `.github/labeler-config-srvaroa.yml`
  - `scripts/translations/**`
- Docs: `AGENTS.md`, `CLAUDE.md`, `ADDING_TOOLS.md`,
`DeveloperGuide.md`,
`WINDOWS_SIGNING.md`, `devGuide/HowToAddNewLanguage.md`,
`frontend/README.md`,
    `frontend/editor/DeveloperGuide.md`

Plus 3 renamed + edited: `editor/vite.config.ts` (env path +
node_modules
  walk-up), `editor/scripts/setup-env.mts` (renamed from `.ts` for
`import.meta.url`), `editor/scripts/build-provisioner.mjs` (resolve
src-tauri
  relative to script).

  ### Verification

  | Check | Result |
  |---|---|
  | `task frontend:typecheck:all` (6 variants) | exit 0 |
  | `task frontend:lint` (eslint + dpdm) | exit 0 |
  | `task frontend:format:check` | exit 0 |
  | `task frontend:test` | 657 tests pass, 50 files |
| `task frontend:build:{core,proprietary,saas,desktop,prototypes}` | all
green |
| `task desktop:build` | full Tauri pipeline →
`Stirling-PDF_2.11.0_x64_en-US.msi` |
  | `playwright test --list --project=stubbed` | 172 tests discovered |

`task desktop:build` exercises the heaviest path — Rust + WiX + MSI
bundle
against the moved `editor/src-tauri/`. If anything in the restructure
was
  wrong it wouldn't have built.

  ### Test plan

  - [ ] `frontend-validation.yml` green
  - [ ] `e2e-stubbed.yml` green
  - [ ] `tauri-build.yml` green on at least one platform
  - [ ] `check_toml.yml` runs on a translation-touching PR

---------

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

frontend/editor/DeveloperGuide.md

@@ -0,0 +1,146 @@
+# Frontend Developer Guide
+
+This document is a guide to the main frontend architectural rules in Stirling-PDF.
+
+## Mode-Specific Code
+
+There are several different builds of the frontend, each with their own mode-specific code.
+The frontend uses [TypeScript Path Aliases](https://www.typescriptlang.org/tsconfig/#paths) to ensure that only relevant code for the configured app version will be present in the build.
+Refer to the various `tsconfig.*.json` files to see the specific path alias order.
+
+The vast majority of the code is in the `src/core` folder, which is the open-source app.
+Other builds, such as the desktop app, use `src/core` as the base layer, and then override various files to change behaviour.
+If an import is `from '@app/a/b'`, this will refer to `src/core/a/b.ts` in the core build of the app, but may refer to `src/desktop/a/b.ts` in the desktop app if that file exists.
+
+It is important to try to minimise the amount of overridden code in the app.
+Often, just one function needs to behave differently in a specific mode.
+For example:
+
+```ts
+// core/file1.ts
+function f1() { /* ... */ }
+function f2() { /* ... */ } // Needs to be overridden in desktop
+function f3() { /* ... */ }
+```
+
+In cases like this, instead of duplicating the entire file, create a new extension module for the core app and override _that_ in the desktop app.
+
+```ts
+// core/file1.ts
+import { f2 } from '@app/file1Extensions';
+
+function f1() { /* ... */ }
+function f3() { /* ... */ }
+```
+
+```ts
+// core/file1Extensions.ts
+export function f2() { /* ... */ } // Original core implementation
+```
+
+```ts
+// desktop/file1Extensions.ts
+export function f2() { /* ... */ } // Custom desktop implementation
+```
+
+Building with this pattern minimises the duplicated code in the system and greatly reduces the chances that changing the core app will break the desktop app.
+
+### Naming extension modules
+
+Extension modules and the functions/hooks they export should be named after **what they do**, not **which build overrides them**.
+Core code must never reference build targets (desktop, saas, etc.) by name — it should simply call a generic extension point and remain unaware of which layer is providing the implementation.
+
+```ts
+// ✅ CORRECT - named after the behaviour, not the build
+// core/useFrontendVersionInfo.ts
+export function useFrontendVersionInfo() { /* stub */ }
+
+// desktop/useFrontendVersionInfo.ts
+export function useFrontendVersionInfo() { /* real Tauri implementation */ }
+```
+
+```ts
+// ❌ WRONG - core code reveals knowledge of the desktop layer
+// core/useDesktopVersionInfo.ts
+export function useDesktopVersionInfo() { /* stub */ }
+```
+
+Similarly, core code should never contain conditionals that check which build is active (e.g. `if (isDesktop)`).
+If behaviour needs to vary, that variation belongs in an extension module - the core simply calls it.
+
+The same principle applies in reverse: code inside `desktop/` is guaranteed to be running in the Tauri environment, so `isTauri()` checks are never needed there either.
+If you find yourself writing `if (isDesktop())` or `if (isTauri())` anywhere, that is a sign the extension point has not been modelled correctly - the build system is already doing that separation for you.
+
+### List extensions
+
+When a build needs to _add_ behaviour rather than _replace_ it, the extension module can return a list of items and let core manage the rendering.
+Core defines the function to return an empty list; the extension build overrides it to return a populated one.
+
+```ts
+// core/toolbarExtensions.ts
+export interface ToolbarButton {
+  label: string;
+  onClick: () => void;
+}
+
+export function getToolbarButtons(): ToolbarButton[] {
+  return [];
+}
+```
+
+```ts
+// desktop/toolbarExtensions.ts
+import { type ToolbarButton } from '@core/toolbarExtensions';
+export { type ToolbarButton };
+
+export function getToolbarButtons(): ToolbarButton[] {
+  return [
+    { label: 'Open folder', onClick: () => { /* ... */ } },
+  ];
+}
+```
+
+```tsx
+// core/Toolbar.tsx
+import { getToolbarButtons } from '@app/toolbarExtensions';
+
+export function Toolbar() {
+  return (
+    <div>
+      <button onClick={() => { /* ... */ }}>Download</button>
+      <button onClick={() => { /* ... */ }}>Print</button>
+      {getToolbarButtons().map((button) => (
+        <button key={button.label} onClick={button.onClick}>
+          {button.label}
+        </button>
+      ))}
+    </div>
+  );
+}
+```
+
+This pattern works well for things like menu items or toolbar actions - anything where a build contributes additional entries to a well-defined set.
+
+### Import aliases
+
+In general, all imports for app code should come via `@app` because it allows for other builds of the app to override behaviour if necessary.
+The only time that it is beneficial to import via a specific folder (e.g. `@core`) is when you want to reduce duplication **in the file you are overriding**. For example:
+
+```ts
+// core/file2.ts
+
+export interface MyProps {
+  // Lots of properties that we don't want to duplicate
+}
+
+export function f1(props: MyProps) { /* ... */ } // Original core implementation
+```
+
+```ts
+// desktop/file2.ts
+
+import { type MyProps } from '@core/file2';
+export { type MyProps }; // Re-export so anything importing file2 can still access MyProps
+
+export function f1(props: MyProps) { /* ... */ } // Custom desktop implementation
+```