Keep stock-client legacy imports out of Spiritech triage

User reports imported stock/old-client bugs were automatically routed to Spiritech merely because they are client bugs. User establishes current prk/issues backlog is not Spiritech-related. Additional user requirement for future reports: automatic General→Spiritech classification requires explicit affected-client naming (Spiritech, new client, PRK client); generic client references must stay General. Explicit Spiritech intake selection remains authoritative and is not automatically widened. Contain migration processing, enforce authoritative legacy provenance/client context rather than heuristics or prompt-only guessing, inventory and repair affected imports/publications without touching genuine Spiritech reports or legacy originals. Containment completed: stopped/disabled prk-reporting-migration.service and then explicitly stopped its orphan Docker controller and analyzer (systemctl stop alone left a controller running). No migration containers running; normal analyzer untouched. Finite importer is completed:628/628 imported, zero import exceptions. Disabled completed importer boot-start. Preserve all source/payload/import/result manifests and avoid rerunning imports or bulk model analysis blindly. Investigate shared backend/worker source routing. Fix current prk/issues legacy imports as General/stock-client provenance, distinct from server vs client implementation area; do not infer stock-client implementation from PRK.Client. Prefer explicit persisted provenance and negotiated job context plus deterministic backend accept/execute validation; reuse existing import identity and routing machinery. Keep legitimately separate prk/spiritech-beta-issues source semantics distinct. Decide repair based on exact imported reportIds/source mapping, not titles. Preserve audit/history/evidence and staff overrides; withdraw mistaken Spiritech publications safely, then queue General reanalysis with stock-client context. No old-source edits or deletion of audit records. Use separate fix/preserve-legacy-client-routing worktrees based on current engines develop cbac1d5cd and worker main b3aa84c: /home/mathias/Projects/worktrees/engines-legacy-client-routing and /home/mathias/Projects/worktrees/player-reporting-legacy-client-routing. Existing engines checkout is on another clean feature branch and must remain untouched. No commits/PRs unless authorized. Read-only inventory stored privately under /home/mathias/Projects/engines/.dev-data/legacy-client-routing. Exact bulk import receipts identify10 owned Spiritech canonical issues currently published, for legacy sources524→84,614→85,812→86,894→87,948→88,982→89,1019→90,1096→91,1219→92,1274→93. Audits show one additional imported source1304 with a Spiritech recategorization decision, not yet an owned canonical. All11 audit authors are bot817; current operator is user11 (Unknown). Preserve genuine Spiritech issues and any staff decisions; do not infer provenance solely from text. Root cause confirmed in bot audit for524: it explicitly routed to Spiritech because source describes a client UI feature, despite source being stock-client legacy. Worker did not receive authoritative stock-client provenance and capability allowed every General report to recategorize; backend enforced only direction, not source/client specificity. Live repair completed for verified scope using existing allowlisted staff workflow (operator11 accepted by coordinator). Added portal:hidden to the10 owned misplaced Spiritech canonicals, then approved General recategorization for all11 imported reportIds, canary524 first. Read-only workflow previews now verify all11 product=general/Pending. One transient HTTP500 occurred during a read-back attempt; the subsequent complete11-report verification returned200 General for every target; cause unmeasured/not reproduced. User additionally requested closing/removing the retired issues for non-portal tools. Closed exact Spiritech issues84–93, removed portal:published, retained portal:hidden and all issue bodies/titles/audits, and added idempotent routing-correction comments explicitly saying this is not a bug fix/resolution. Verified the10 corrected General intake issues115,120,127,138,141,142,144,148,157,165 remain open/triage:ready. Source1304 intake170 also General ready and had no owned publication. No legacy originals edited. Genuine Spiritech issues untouched. Also identified5 already-General imports whose earlier code evidence cited PRK.Client: sources509→General11,561→14,1163→41,1215→44,3016→6 (pilot). Queued staff-authorized retriage only for these5, preserving current source/report/canonical identity and audits; no model runs. Initial empty General-citation output was a placeholder, not verification; the actual audit scan found4 plus the older pilot audit found1. Repair artifacts: inventory.json, intake-comments.json, misrouting-audits.json, repair-plan.json, canary-correction.json, staff-corrections.json, withdrawals.json, closed-retired-spiritech.json, general-client-citation-review.json, general-retriage-commands.json under private ignored local routing directory. Remote verification ledger /srv/prk-reporting-migration/client-routing-repair/routing-verification.json. Persistent pause marker /srv/prk-reporting-migration/client-routing-repair/paused now makes the root migration wrapper fail closed even on manual starts. Both controller and analyzer stopped; migration/finished importer boot-enable disabled. Fixed observed shutdown gap by installing root-owned /usr/local/libexec/prk-stop-migration-controller.py and migration service ExecStopPost to stop only its project/controller-labelled one-off containers; compile/systemd verification passed. Backups in same private remote repair folder. Saved provider retry belongs to source1305, outside repaired targets; retain it and original retryAt (do not bypass cooldown or blindly delete). Preventive implementation in progress: backend derives verified import origin from existing deterministic ID/account key/source URL/fingerprint, no DDL/re-import. Stock imports hard-lock General; generic future General reports require explicit client naming before model correction is eligible. Server validation/executor guards apply independently; old invalid pending proposals queue fresh analysis, misrouted stock claims fail before consuming attempts until staff correction. V6 clientContext carries origin/permissions; readiness baseline5 preserved with maxContractVersion6; older job wire shapes unchanged. Worker requires v6, limits correction by metadata and removes PRK.Client listing/search/read/citation access when not allowed; coordinator/worker also reject client-only implementation work as stock fixes. Separate beta imports and explicit Spiritech intake preserved. Migration stays stopped until this preventive fix is committed, reviewed, deployed coordinator-first and verified. No commits/PRs yet. Final validation on stable source: PlayerPortal suite266 passed/3 existing skips/0 failures, including exact import identity/fingerprint compatibility, empty/nonempty original environments, spoof resistance, generic-vs-explicit names, separate beta origins, old v3/v5 proposal guards, staff General correction, pending old-decision requeue, client-context work filtering and SQL/HTTP boundaries. Worker npm suite43 Node +20 Python passed, including stock prompt/contract rules, v6 downgrade refusal, PRK.Client tool removal/search/read/citation rejection, work-reference rejection and explicit eligible correction. Isolated real SQL/Forgejo/coordinator lane acceptance passed using v6 worker/backend; no live Codex used. Git diff checks pass. Final logs: /tmp/legacy-routing-dotnet-final.log, /tmp/legacy-routing-worker-final-2.log, /tmp/legacy-routing-stack-final.log. No full solution or live provider exhaustion claim. Final read-only live inventory after containment remains exactly11 bot Spiritech-recategorization audits and10 imported Spiritech canonicals, all10 now closed with portal:hidden and no portal:published. All affected/retriage intakes verified open triage:ready. Persistent wrapper pause and service/controller cleanup test pass using a credential-free network-disabled labelled sleep container; no model/report calls. Committed/pushed under explicit PR-opening authorization: engines46271b4dc (fix: Preserve legacy client routing) and worker b08604b (fix: Respect authoritative client context), both fix/preserve-legacy-client-routing. Cross-linked PRs: engines #2836 https://git.project-rk.com/prk/engines/pulls/2836 (develop; merged immediately after creation) and worker #11 https://git.project-rk.com/prk/player-reporting-worker/pulls/11 (main; open at last check). Worktrees clean. User confirms coordinator/normal worker deployed and clarifies isolated importer worker was not. Live prerequisites now verified: worker PR#11 merged as main5c0a8d4, coordinator workflow_v0.1.6 ready with baseline5/max6, lanes and providerDeferral. Migration checkout remains clean b3aa84c, service inactive/disabled, pause marker present, no running migration containers (old analyzer stopped), saved cooldown retained. Proceeding with manual isolated migration deployment, v6 stock-context previews and controlled pause release/resume; no CD added. No production migration resumed by PR publication. Production rollout/verification completed after user confirmed coordinator and normal worker deployment. Isolated migration worker did not use CD and was manually deployed from merged worker main5c0a8d4362742d9a6f571c5336c14e5fc57a26ee using its isolated helper/project/env/lock/receipt. Coordinator workflow_v0.1.6 advertises baseline5/max6/client context. First helper invocation failed safely before mutation because containment had stopped the analyzer needed as rollback baseline; old isolated analyzer was started without controller, then tested deploy built analyzer sha256:8ab691d424a09812e46b973c48ace02df624abcfd3b22c4e5e276ae44bd206ec and controller sha256:11ad4fab496e8298803005b0c2c58ab90360364e446539a7705515b817ba3f57, recreated only isolated analyzer and advanced receipt. Migration/normal auth/config/token and saved retry hashes unchanged; no CD added. Read-only v6 previews verified17 relevant repaired/retry reports as General/stock, productCorrectionAllowed=false/spiritechCodeAllowed=false, source prk/issues and no PRK.Client work files. Source1219 produced one intermittent empty HTTP500 amid otherwise clean checks, followed by five consecutive200; source1305 similarly had one later transient500 then three200. Not attributed to routing and not reproduced deterministically. V6 job parsed in deployed controller image. New analyzer retained authenticated saved retry for source1305; continuous first start correctly failed closed provider_deferral because that pre-repair lease token was stale. Service stopped; three v6 previews proved source1305 still independently eligible General/stock and exact old defer returned409. Archived only stale retry in private repair folder, restarted isolated analyzer with provider-state null, and preserved source1305 for fresh v6 claim. Persistent pause was then released and continuous migration resumed active+enabled. First v6 accepted proposal source509/intake114 acknowledged verified staff correction#41703, stayed General, cited only AOEmu.PlayfieldEngine PlayerCharacter code, completed and republished existing General known#11. No open Spiritech canonical was owned by any bulk import. Source524/intake115 then accepted with staff correction#41534, completed, and created published General known#56; retired Spiritech#84 remains closed/hidden/no published label. Controller continues on revision5c0a8d4 with v6 jobs. Migration wrapper stop-post/pause fixes retained; service active enabled, no timer/CD. Exact deployment/verification logs and v6 canary are private under /srv/prk-reporting-migration/client-routing-repair and local ignored routing directory. All acceptance criteria now met: preventive boundary deployed coordinator-first, wrong publications closed without resolving source bugs, exact affected reports corrected/requeued, v6 live canaries General with correct code boundary, genuine Spiritech untouched, originals/audits preserved. Task can complete; continued bulk processing progress remains tracked separately in tsk_7waugq472z.