feat(n8n): add scheduled quality-scan workflow

The original docs described two n8n workflows but the repository only ever
shipped one (return-processing); the sketched second workflow (knowledge
sync) depends on RAGcore, which isn't connected here, so it stays deferred.

Add POST /api/v1/integrations/n8n/scheduled-scan (X-Service-Token
protected, same pattern as the return callback), calling the same
run_scan() the manual "Run quality scan" UI action uses and recording a
service-actor data_quality_scan_run audit event. run_scan() already only
creates an issue for a condition without one open, so overlapping triggers
do no duplicate domain work.

n8n/mobilityops-scheduled-quality-scan.json (hourly schedule + manual test
trigger, both feeding the same HTTP call) ships "active": false so it can't
fire anywhere until deliberately published. Verified live against the
local n8n instance via the Manual test trigger: full green execution, and
the resulting data_quality_scan_run audit event (actor_type=service,
actor_label="n8n scheduled scan") confirms the real round trip, not just a
contract test. deploy/unraid/setup-scheduled-scan.sh mirrors the existing
return-workflow publish script for the shared Unraid n8n.

docs/11-n8n-integration.md

@@ -18,7 +18,34 @@ Steps:
 
 The starter export is `n8n/mobilityops-return-processing.json`. Claude may correct its credentials and callback route but must preserve idempotency.
 
-## Optional second workflow: knowledge sync
+## Second live workflow: scheduled quality scan
+
+RAGcore is not connected in this environment, so the originally sketched "knowledge sync"
+workflow below remains deferred (see "Deferred: knowledge sync"). The second implemented
+workflow does not depend on RAGcore or MCP Hub, so it is not blocked by them.
+
+Input: hourly schedule trigger, or a manual trigger for on-demand testing.
+
+Steps:
+
+1. call the narrow, service-token-protected `POST
+   /api/v1/integrations/n8n/scheduled-scan` endpoint;
+2. the endpoint runs the same deterministic `run_scan()` domain function the manual
+   "Run quality scan" UI action uses, and records a `data_quality_scan_run` audit event
+   with `actor_type=service`;
+3. return counts of newly created issues per rule type.
+
+`run_scan()` only ever creates an issue for a condition that does not already have one
+open, so a duplicate or overlapping trigger (a manual test run firing close to the
+scheduled one, or a retried HTTP call) does no duplicate domain work.
+
+The starter export is `n8n/mobilityops-scheduled-quality-scan.json`, imported and
+published the same way as the return-processing workflow (see
+`deploy/unraid/setup-scheduled-scan.sh` and `docs/17-runbook.md`). It ships with
+`"active": false` so it cannot fire against any environment until deliberately
+published with a real service token.
+
+## Deferred: knowledge sync
 
 Input: manual trigger or manifest-changed event.
 
@@ -28,7 +55,8 @@ Steps:
 2. call RAGcore ingestion/sync API;
 3. record per-document results through MobilityOps integration status API.
 
-This workflow is useful but must not delay the core demo if RAGcore's final API is not ready.
+Deferred until RAGcore's live ingestion API is available in this environment; must not
+delay or block the core demo.
 
 ## Outbox dispatcher