Reliability fix: scaling an instance could "succeed" on the Hub side without the…

• Reliability fix: scaling an instance could "succeed" on the Hub side without the container ever actually starting, and a non-zero scale-down could revert on its own later.

1. scale-app ran docker compose up --scale and reported success as soon as the CLI command returned — without ever checking that the requested replica count was actually alive (a new instance crashing immediately never appeared in docker ps, yet the Hub still showed the app as started). The agent now waits for the container count to actually converge before answering, and reports an explicit error otherwise.

2. On the Hub side, resyncing the compose file after a scale (the step that durably writes the new replica count to the file on disk) was best-effort: a mere network/agent failure made it fail silently, leaving the compose file with the old count. An unrelated redeployment (sibling app, network change) then replayed that stale file and undid the scale without telling anyone. This resync is now retried once and then mandatory: if it still fails, the whole scale is reported as failed instead of being silently treated as durable.