fix: hide phantom projects from showing in the frontend when deleted

[kmendell]

Checklist

• This PR is not opened from my fork’s main branch
• All new user-facing strings are translated via Paraglide (m.*())

What This PR Implements

Fixes:

Changes Made

Testing Done

AI Tool Used (if applicable)

Additional Context

Disclaimer Greptiles Reviews use AI, make sure to check over its work.

To better help train Greptile on our codebase, if the comment is useful and valid Like the comment, if its not helpful or invalid Dislike

To have Greptile Re-Review the changes, mention greptileai.

Greptile Summary

This PR fixes phantom project re-imports that occurred when a project was deleted without removing its files — the original directory remained on disk and was picked back up by the filesystem watcher. It does this by renaming deleted-but-preserved project directories to a .arcane-trash-* sibling and teaching the discovery walker to skip that prefix.

• Quarantine on soft delete (project_service.go): after the DB row is successfully deleted, the project directory is atomically renamed to .arcane-trash-<name>-<unix> so discovery never re-imports it. The rename is correctly placed after the DB delete, avoiding the stale-path inconsistency that would have occurred if the rename had been done first.
• Discovery filter (discovery.go): the walker now skips .arcane-trash-* directories with a targeted prefix check, leaving legitimate dot-named user directories (e.g. .hidden) visible — confirmed by the new test.
• Orphaned GitOps sync cleanup: a new CleanupOrphanedSyncsOnStartup sweeps sync records whose environment no longer exists; DeleteEnvironment now clears associated syncs and project references inside a single transaction; RegisterAutoSyncJobsOnStartup filters out orphan-backed syncs via a subquery.

Confidence Score: 5/5

Safe to merge. The quarantine rename is correctly ordered after the DB delete, the discovery filter is surgical, and the GitOps sync cleanup is wrapped in a transaction.

All three functional changes (soft-delete quarantine, discovery filter, and orphaned-sync cleanup) are logically sound, well-tested, and consistent with the existing codebase patterns. No new unsafe orderings or data-loss paths are introduced.

No files require special attention.

Comments Outside Diff (1)

1. backend/internal/services/project_service.go, line 2348-2365 (link)

   File quarantine races ahead of DB delete

   The rename to .arcane-trash-* at line 2354 happens before the database row is deleted at line 2363. If s.db.Delete(proj) fails, the project record survives in the DB with Path pointing to the original directory (which no longer exists there), while the actual files sit in the trash path. The project will still appear in the frontend but every operation that touches proj.Path will break. Previously, with removeFiles=false, nothing was moved so a DB failure left both sides consistent. This PR introduces the inconsistency.

   Move the quarantine block to after s.db.Delete succeeds. If the quarantine fails after a successful DB delete it can be logged as a warning instead of returned as an error — the project is already gone from the DB and a failed rename is less harmful than leaving the DB record with a stale path.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: backend/internal/services/project_service.go
   Line: 2348-2365
   
   Comment:
   **File quarantine races ahead of DB delete**
   
   The rename to `.arcane-trash-*` at line 2354 happens before the database row is deleted at line 2363. If `s.db.Delete(proj)` fails, the project record survives in the DB with `Path` pointing to the original directory (which no longer exists there), while the actual files sit in the trash path. The project will still appear in the frontend but every operation that touches `proj.Path` will break. Previously, with `removeFiles=false`, nothing was moved so a DB failure left both sides consistent. This PR introduces the inconsistency.
   
   Move the quarantine block to after `s.db.Delete` succeeds. If the quarantine fails after a successful DB delete it can be logged as a warning instead of returned as an error — the project is already gone from the DB and a failed rename is less harmful than leaving the DB record with a stale path.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

_{Reviews (2): Last reviewed commit: "fix: hide phantom projects from showing ..." | Re-trigger Greptile}

[kmendell]

• fix: hide phantom projects from showing in the frontend when deleted #3136 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[getarcaneappbot]

Container images for this PR have been built successfully!

• Manager: ghcr.io/getarcaneapp/manager:pr-3136
• Agent: ghcr.io/getarcaneapp/agent:pr-3136

Built from commit 69fbdf8