fix(scheduled-ops): run stack lifecycle schedules on remote nodes and harden run visibility (#1260)

* fix(scheduled-ops): run stack lifecycle schedules on remote nodes and harden run visibility

Stack lifecycle schedules (Restart, Stop, Take Down, Start, Backup Stack
Files) now run against whichever node the schedule targets, local or
remote. Each remote run proxies to that node's own stack-operation
endpoint, so a hub-managed schedule reaches the node that actually holds
the stack. Restart with a service subset restarts each selected service
and, if one fails, names the services already restarted so run history
reflects the stack's partial state. Auto-start on a remote node runs that
node's own pre-deploy scan-policy check against the images it holds.

Add POST /api/stacks/:name/backup to trigger an on-demand backup of a
stack's compose and env files (the same rollback snapshot a deploy
takes); it backs the remote backup schedule and is available to operators
on its own.

A scheduled task that reaches execution on an unpaid licence is now
skipped and written to run history as a failed run, so a manual trigger
that returned a queued response never silently disappears.

Test plan:
- Backend unit + integration: scheduler-service (remote proxy per action,
  per-service fan-out, auto-start policy delegation, remote-failure and
  no-credentials paths, unpaid-tier skip), stack-backup-route
  (auth/role/paid/404/400/500), scheduled-tasks-routes.
- Frontend component test for the schedules view (list, prefill, node
  filter, create payload).
- tsc and lint clean on both packages.

* fix(scheduled-ops): lock the stack-files backup route against concurrent stack ops

The stack-files backup writes the same slot the pre-deploy rollback
snapshot uses, so running it while a deploy, update, or rollback is in
flight on the same stack could overwrite the rollback point. The backup
route now takes the per-stack operation lock (as deploy/down/restart do)
and returns 409 when the stack is busy, keeping the rollback snapshot
intact. Adds the 'backup' action to the stack-op lock type and a busy
participle for the 409 message.

* fix(scheduled-ops): enforce backup-path containment inline at the filesystem sink

The on-demand backup route passes the stack name straight into
backupStackFiles, so resolve the backup directory against the backup root
and confirm containment with an inline startsWith check before the
mkdir/copy/write sinks, matching the barrier restoreStackFiles already
uses. The stack name is validated at the route and again by
resolveStackDir, so this is defense in depth that also closes a
static path-injection finding on the new call path.

backend/src/services/FileSystemService.ts

@@ -485,7 +485,16 @@ export class FileSystemService {
     const debug = isDebugEnabled();
     const t0 = Date.now();
     const stackDir = this.resolveStackDir(stackName);
-    const backupDir = this.getBackupDir(stackName);
+    // Canonical js/path-injection barrier (mirrors restoreStackFiles): resolve the
+    // backup path against the backup root and confirm containment inline, so the
+    // mkdir/copy/write sinks below operate on a validated path. stackName is
+    // already validated by resolveStackDir above; this re-establishes containment
+    // at the backup sinks themselves so static analysis sees the barrier.
+    const backupRoot = path.resolve(getBackupBaseDir());
+    const backupDir = path.resolve(backupRoot, String(this.nodeId), stackName);
+    if (!backupDir.startsWith(backupRoot + path.sep)) {
+      throw Object.assign(new Error('Path escapes backup directory'), { code: 'INVALID_PATH' });
+    }
     await fsPromises.mkdir(backupDir, { recursive: true });
 
     // Clear stale managed files from the backup slot before writing the current
@@ -493,11 +502,9 @@ export class FileSystemService {
     // stack since the last backup (e.g. a deleted .env or a switched compose
     // variant) would otherwise linger here and a later restore would resurrect
     // it, breaking the faithful-revert guarantee. Scope is the protected set
-    // Sencho writes; .timestamp is rewritten below. Containment is re-checked at
-    // the sink, rooted at the backup base, for the same reason restoreStackFiles
-    // does it. A clear failure is logged but not fatal: it only risks a stale
-    // future rollback, so it should not block an otherwise valid deploy.
-    const backupRoot = path.resolve(getBackupBaseDir());
+    // Sencho writes; .timestamp is rewritten below. A clear failure is logged but
+    // not fatal: it only risks a stale future rollback, so it should not block an
+    // otherwise valid deploy.
     for (const file of PROTECTED_STACK_FILES) {
       const stale = path.resolve(backupRoot, path.join(backupDir, file));
       if (!stale.startsWith(backupRoot + path.sep)) continue;