Fix miren app TUI showing auto for fixed-concurrency services

[evanphx]

Summary

• Added concurrency_mode and num_instances fields to the ServiceConfig RPC type
• Populated these fields from the ConfigSpec in the GetConfiguration handler
• Fixed the miren app TUI View() to check per-service concurrency mode instead of the deprecated top-level HasConcurrency() which always returned false

Test plan

• go generate ./api/app/ regenerates cleanly
• hack/it servers/app — all 42 tests pass
• Deploy app with [services.web.concurrency] mode = "fixed" num_instances = 2, verify miren app shows "(fixed)"
• Verify m app list still shows "(fixed)" (regression check)
• Verify auto-concurrency apps still show "(auto)" or "(idle, will scale on traffic)"

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 1a0fcb07-1843-427c-95e0-d8fbc4e3b855

📥 Commits

Reviewing files that changed from the base of the PR and between b9c5b6b and 406ccec.

📒 Files selected for processing (1)

• servers/app/app.go

🚧 Files skipped from review as they are similar to previous changes (1)

• servers/app/app.go

---

📝 Walkthrough

Walkthrough

The ServiceConfig schema and generated RPC code were extended with two fields: concurrency_mode (string) and num_instances (int32), including presence checks, getters, and setters. The RPC YAML/type indices were updated accordingly. Server-side GetConfiguration now populates these fields from each service spec. The CLI app view was updated to detect services with concurrency_mode == "fixed" and adjust instance labeling to show fixed, idle, or auto instance states.

📝 Coding Plan

• Generate coding plan for human review comments

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@api/app/rpc.yml`:
- Around line 50-55: The RPC schema exposes concurrency_mode and num_instances
on ServiceConfig but servers/app/app.go only reads service_env from
cfg.Services(), so clients can submit edits that are ignored; either remove
concurrency_mode and num_instances from the mutable Configuration payload in
rpc.yml or wire them through AppInfo.SetConfiguration so updates persist: update
the setConfiguration handling to accept and persist these fields (reference
ServiceConfig, getConfiguration, setConfiguration, AppInfo.SetConfiguration, and
cfg.Services()) or remove the two fields from ServiceConfig until persistence is
implemented.

In `@servers/app/app.go`:
- Around line 359-360: Only call sc.SetConcurrencyMode and sc.SetNumInstances
when the source service actually carries those settings: check svc.Concurrency
for nil and use the presence checks (e.g., svc.Concurrency.HasMode() /
svc.Concurrency.HasNumInstances() or equivalent fields) before calling
SetConcurrencyMode(svc.Concurrency.Mode) or
SetNumInstances(int32(svc.Concurrency.NumInstances)); this preserves omission
semantics so HasConcurrencyMode()/HasNumInstances() on sc remain false when the
source had no explicit values.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: d8e0770a-da5f-474e-b282-c9c36c74bf97

📥 Commits

Reviewing files that changed from the base of the PR and between 9223d5c and b9c5b6b.

📒 Files selected for processing (4)

• api/app/app_v1alpha/rpc.gen.go
• api/app/rpc.yml
• cli/commands/app.go
• servers/app/app.go