fix: move swarm stacks to be under projects

[kmendell]

Checklist

• This PR is not opened from my fork’s main branch

What This PR Implements

Fixes: #2226

Changes Made

Testing Done

• Development environment started: ./scripts/development/dev.sh start
• Frontend verified at http://localhost:3000
• Backend verified at http://localhost:3552
• Manual testing completed (describe):
• No linting errors (e.g., just lint all)
• Backend tests pass: just test backend

AI Tool Used (if applicable)

AI Tool:
Assistance Level:
What AI helped with:
I reviewed and edited all AI-generated output:
I ran all required tests and manually verified changes:

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 moves swarm stack projects (saved compose configurations) under the Projects section, separating them from live/running stacks visible in the Swarm section. On the backend it adds a swarm_stack_projects table (with PostgreSQL and SQLite migrations), a filesystem-to-DB sync mechanism, new CRUD endpoints (/swarm/stackprojects), a DownStack endpoint that stops running services while preserving saved files, and a rename operation in UpdateStackSource. The frontend introduces new routes under /projects/swarm/* and removes the "Stacks" nav item from the Swarm section. The "Stacks" Swarm page is retained for live runtime stacks only.

Confidence Score: 5/5

Safe to merge; all remaining findings are non-blocking P2 suggestions.

The core logic — migration, DB-backed sync, new CRUD endpoints, rename with rollback, DownStack — is structurally sound and well-tested. The only new finding not covered by prior comments is a P2 double-sync in GetStackProject (two full filesystem scans per request due to GetStackSource redundantly re-syncing). This is a performance inefficiency, not a correctness issue. Both previously flagged issues (TOCTOU race in upsert, $effect state update) remain open but do not block merge.

backend/internal/services/swarm_service.go (double-sync in GetStackProject / dead sync bool parameter)

Prompt To Fix All With AI

This is a comment left during a code review.
Path: backend/internal/services/swarm_service.go
Line: 1390-1395

Comment:
**Double filesystem sync per `GetStackProject` call**

`GetStackProject` calls `getStackProjectRecordInternal(sync=true)` (sync #1), then calls `GetStackSource` which calls `getStackProjectRecordInternal(sync=true)` again (sync #2). Each sync reads the entire environment directory, stats every compose/env file, and parses every compose file to count services. `UpsertStackProject` chains `UpdateStackSource` → `syncStackProjectRecordInternal` (sync #3 via write-path) → `GetStackProject` (syncs #4 and #5).

The `sync bool` parameter on `getStackProjectRecordInternal` exists precisely to let callers skip the sync when one has already run, but it is always `true` at every call site, making it dead code and the double-sync unconditional.

A direct fix: read the compose file from `stackProject.Path` (already fetched on line 1390) instead of delegating to `GetStackSource`, which redundantly fetches the record a second time:

```go
// Instead of: source, err := s.GetStackSource(ctx, environmentID, stackName)
// Use stackProject.Path directly:
composeContent, err := os.ReadFile(filepath.Join(stackProject.Path, swarmStackComposeFilename))
...
envContent := ""
envBytes, _ := os.ReadFile(filepath.Join(stackProject.Path, swarmStackEnvFilename))
if err == nil { envContent = string(envBytes) }
```

This eliminates sync #2 and the redundant DB query. The `sync bool` parameter can then be reserved for callers that genuinely skip syncing.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (2): Last reviewed commit: "fix: move swarm stacks to be under proje..." | Re-trigger Greptile}

[kmendell]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[kmendell]

• fix: move swarm stacks to be under projects #2234 👈 (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/arcane:pr-2234
• Agent: ghcr.io/getarcaneapp/arcane-headless:pr-2234

Built from commit f3338ad

[github-actions]

This pull request has merge conflicts. Please resolve the conflicts so the PR can stay up-to-date and reviewed.

[github-actions]

This pull request has merge conflicts. Please resolve the conflicts so the PR can stay up-to-date and reviewed.