[BUG] 2.45.0 CE: manual git redeploy permanently degrades GitOps workflow to 'unknown' and stops auto-update drift sync; only stack recreation restores it

Before you start please confirm the following.

• Yes, I've searched similar issues on GitHub.
• Yes, I've checked whether this issue is covered in the Portainer documentation.

Problem Description

On Portainer CE 2.45.0, a GitOps workflow (stack created from a git repository) that is manually redeployed after creation gets permanently degraded: its file-validation statuses flip to unknown and, more importantly, the workflow appears to be skipped by the source's polling scan afterwards — normal branch-push auto-updates no longer apply until the stack is deleted and recreated.

This looks like a functional regression in the same family that was fixed in 2.42.0 ("Fixed GitOps auto-update skipping re-deployment when the commit hash was persisted before the deployment attempt"), resurfacing via the manual-redeploy path in the 2.45 Source/Workflow scheduler.

Observed on 5 independent workflows across 4 environments (Docker Standalone + Portainer Agent connected over tunnels), private GitHub repo, compose file at repository root, source polling interval 30m.

Expected Behavior

After a manual redeploy, the workflow keeps (or re-runs) its file validation and stays visible to the source scan, so subsequent pushes to the bound branch continue to trigger automatic drift-sync deployments.

Actual Behavior

1. After the manual redeploy: artifact.status -> unknown, files[0].refStatus / pathStatus -> unknown, while status.source and status.target remain healthy.
2. The state never self-heals (observed >48h across dozens of 30m poll cycles). The parent source's own lastSync stays fresh while the workflow-level lastSyncDate is frozen at the redeploy timestamp.
3. Calling the git redeploy / reconcile endpoints (PUT /api/stacks/{id}/git/redeploy, Reconcile) does not restore the statuses.
4. Functional impact, not just telemetry: after a subsequent commit was pushed to the bound branch, the workflow did not auto-update across multiple poll windows; the change had to be applied manually on the host (equivalent of docker compose up -d). Control group: workflows from the same batch that were only created (no manual redeploy) remain fully green and continue to sync correctly.
5. The only known workaround is deleting and recreating the stack from the same source (pure-created workflow goes green again) — for production deployments that means a real service interruption just to restore CI/CD drift detection.

Steps to reproduce the behavior

1. Create a stack via POST /api/stacks/create/standalone/repository from a git repo (compose at repository root) with AutoUpdate (e.g. 30m). After the first scan the workflow shows artifact=healthy, refStatus=healthy, pathStatus=healthy.
2. Trigger one manual redeploy (UI "Redeploy" button, or PUT /api/stacks/{id}/git/redeploy).
3. Workflow statuses flip to unknown (source/target stay healthy); workflow lastSyncDate freezes.
4. Wait past several 30m poll cycles — status never recovers, scheduler log shows no error for the affected workflow.
5. Push a new commit to the bound branch — no auto-update deployment happens.
6. Delete + recreate the stack from the same source — green again, auto-update restored.

Portainer logs / portainer info

• Portainer CE 2.45.0 (Docker, Linux, behind reverse proxy).
• GET /api/gitops/workflows for an affected workflow: artifact.status = "unknown", files[0].refStatus = "unknown", files[0].pathStatus = "unknown", status.source = healthy, status.target = healthy; lastSyncDate frozen at the redeploy moment while the source's lastSync continues to advance.
• Related but distinct issues: #13288 (false "git reference could not be found" for subdirectory compose), #13258 (AutoUpdate.Interval never persisted), #13291 (orphaned workflow refs after 2.43 migration). None covers the manual-redeploy -> permanent skip path.