feat(setup): first-run gate, hub-first preview, honest wording — setup before the app

Stefan's live findings, all four addressed at the root:

- 'In 3 Fragen loslegen' read like ad copy → the entry is now plainly
  'Einrichtung starten' / 'Start setup'.
- The setup button sat permanently on the Welcome page of a running
  app ('setup after the app runs is backwards' — reported twice). A
  fresh install now starts INSIDE the setup: SetupGateScreen hosts
  the wizard embedded as the page (new embedded/onFinished modes on
  GuidedSetupDialog), with an explicit 'Später einrichten' skip.
  Welcome loses the setup button entirely and stays a calm intro.
- Re-running the setup later lives in Settings → General ('Run setup
  again…'), the single post-first-run home.
- 'You must grant access first and only then see what will be done':
  the preview used to spawn the chain CLI, whose first run could pop
  the macOS permission prompt BEFORE the plan was ever shown. The
  preview now calls the new PlanSetup RPC over the live hub
  connection (no subprocess, nothing granted); the CLI remains only
  a fallback when no hub is reachable — and applying stays the
  explicit, separate step.

Widget tests: gate hosts the wizard + skip/cancel leave it; CLI-path
tests drive the fallback through the new hub-preview test seam.
Suite 76 green, analyze clean.

Signed-off-by: flemming-it <stefan.a.flemming@googlemail.com>

lib/data/hub.dart

@@ -259,6 +259,41 @@ class HubService {
   /// hub is up and needs a token fix, not an endpoint fix.
   Future<HubProbeResult> probeHealth() => _client.probe();
 
+  /// Assemble the guided-setup plan over the live hub connection —
+  /// a pure computation, nothing applied. Returned in exactly the
+  /// `chain init --plan-json` map shape so the wizard renders the
+  /// same preview from either source. Using the hub avoids spawning
+  /// the CLI for the preview: on macOS that subprocess can be the
+  /// app's first file-system touch and pop a permission prompt
+  /// BEFORE the operator saw what would be set up.
+  Future<Map<String, dynamic>> planSetup({
+    required String scenario,
+    required String intent,
+    required String target,
+    bool requireApproval = false,
+    bool dataMustStayLocal = false,
+    bool allowUnsignedModules = false,
+  }) async {
+    final r = await _client.planSetup(
+      scenario: scenario,
+      intent: intent,
+      target: target,
+      requireApproval: requireApproval,
+      dataMustStayLocal: dataMustStayLocal,
+      allowUnsignedModules: allowUnsignedModules,
+    );
+    return {
+      'profile': r.profile,
+      'modules': List<String>.from(r.modules),
+      'starter_flow': r.starterFlow,
+      'runbook': r.runbook,
+      'curated_docs': List<String>.from(r.curatedDocs),
+      'require_signatures': r.requireSignatures,
+      'worm_audit': r.wormAudit,
+      'approval_step': r.approvalStep,
+    };
+  }
+
   /// Configured module stores (+ the bundled seed) for the store manager.
   Future<List<StoreSource>> listStores() => _client.listStores();