Fix/app config save guard

[psanghvi17]

PR Checklist

• Linting Test is passing
• Code is well documented
• If applicable, a PR in the epinio/docs repository has been opened

Summary

Updates the application edit flow so configuration changes can still be saved for non-running apps without always forcing an immediate restart, while still triggering restart/deploy when the app is running or when instance count changes require it.

Occurred changes and/or fixed issues

• Removed the UI behavior that fully blocked config saves for non-running apps.
• Added app-edit save logic to decide when restart should be sent to the backend:
  • restart when the app is already running and has an image
  • restart when instance count changes
  • otherwise save config without forcing immediate restart
• Preserved explicit 0 instance values in app forms and manifest parsing by replacing || 1 with ?? 1.
• Kept the regular validation flow active so save is not disabled just because the app is not running.

Technical notes summary

• dashboard/pkg/epinio/models/applications.js
  • replaced canSaveConfiguration / cannotSaveConfigurationReason with canRestartAfterConfigSave
  • restart intent is now about rollout behavior, not whether the save is allowed
• dashboard/pkg/epinio/edit/applications.vue
  • introduced shouldRestartOnSave
  • compares previous vs current instance count
  • sends update({ restart: shouldRestartOnSave }) instead of always relying on default restart behavior
• dashboard/pkg/epinio/components/application/AppInfo.vue
  • preserves instances: 0 using nullish coalescing
  • removes the warning banner that previously explained save was disabled
• dashboard/pkg/epinio/components/application/AppSource.vue
  • preserves instances: 0 when loading values from parsed manifest data
• Main behavioral change:
  • saving recovery-oriented config changes is allowed again
  • restart is only requested when it is actually needed

Areas or cases that should be tested

• Local testing browser: Chrome
  Reviewer should ideally test with a different browser.

• Save config for a running app:

  1. Open an app that is in running state.
  2. Edit env vars/settings/routes/config-related values.
  3. Save.
  4. Verify the request succeeds and the backend still performs restart/redeploy behavior.

• Save config for a non-running app:

  1. Open an app with an existing workload that is not running.
  2. Edit env vars/settings/routes/config-related values.
  3. Save.
  4. Verify the request succeeds without UI hanging on a restart path.
  5. Verify the changes remain saved after refresh.

• Scale from 0 -> 1 in the app edit form:

  1. Open an app with 0 instances.
  2. Change instances to 1.
  3. Save.
  4. Verify restart/deploy is requested and the app starts.

• Edit config while also changing instances:

  1. Open an app with 0 instances or another non-running state.
  2. Change instances and another config field in the same save.
  3. Save.
  4. Verify both the config changes and the instance change are applied correctly.

• Manifest import / parsed source values:

  1. Load or import config with instances: 0.
  2. Verify the UI keeps 0 and does not silently convert it to 1.

Areas which could experience regressions

• App edit save behavior, especially the payload sent to the backend for restart
• Instance scaling from the edit form, especially 0 -> >0
• Any flows depending on previous UI guardrails that disabled save for non-running apps
• Manifest/source parsing for instance values
• Mixed saves where instance changes and config changes are submitted together
• Any UI assumptions that equate “non-running” with “save must be blocked”