Only allow Tauri imports in the desktop app (#5995)

# Description of Changes
Adds an eslint rule to disallow importing any Tauri APIs outside the
desktop folder to help hint to developers that they should be following
the frontend architecture.

While doing this, I also discovered that you can provide a custom
message in the `no-restricted-imports` rule, which is nicer than the
comments that I'd previously added to the eslint config file to explain
why they weren't allowed:

```text
/Users/jamesbrunton/Dev/spdf1/frontend/src/core/components/shared/config/configSections/GeneralSection.tsx
  19:1  error  'src/core/contexts/PreferencesContext' import is restricted from being used by a pattern. Use @app/* imports instead of absolute src/ imports              no-restricted-imports
  20:1  error  '../../../../../core/contexts/AppConfigContext' import is restricted from being used by a pattern. Use @app/* imports instead of relative imports          no-restricted-imports
  21:1  error  '@tauri-apps/core' import is restricted from being used by a pattern. Tauri APIs are desktop-only. Review frontend/DeveloperGuide.md for structure advice  no-restricted-imports
```

frontend/DeveloperGuide.md

@@ -45,6 +45,84 @@ 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: