fix: await change tracking when applications and microservices are updated

[nilsonfh]

What this fixes

Three loops in the application and microservice update paths iterate with
forEach(async ...), so the ChangeTrackingService updates inside them are started
and never awaited. The endpoint can return before they are written, and an agent
polling in that gap sees no pending change: the update is stored in the Controller
and never reaches the node.

src/services/application-service.js (two loops) and
src/services/microservices-service.js (one loop) become for ... of, so every
ChangeTrackingService.update is awaited inside the transaction that made the change.

How it was found

Measured on Controller 3.8.2 with Edgelet v1.0.3-rc.1, ten agent nodes, while
building an emulated lab for a grid-edge platform:

• PUT /api/v3/application and PUT /api/v3/application/yaml stored a changed
  microservice image, and no node ever applied it — the change sat in the Controller
  indefinitely.
• PATCH /api/v3/microservices/<uuid> (including iofogUuid in the body) applied the
  same change in about 33 s.

The difference between the two is the awaited change tracking, not the payload.

Scope and risk

No API change, no schema change, no behaviour change other than the ordering the code
already intended. for ... of inside an async function preserves the existing
sequential semantics that forEach(async ...) only appeared to have.

Verification

• npx standard@17 clean on both changed files (same version as the repo's
  devDependency).
• Running as a patch on top of 3.8.2 in that lab since 17 September 2026: application
  updates reach nodes, and a cohort rollout of 10 nodes driven through the
  application API behaves like one driven through the per-microservice endpoint.

Note: npm ci fails on develop for an unrelated reason (ERESOLVE:
sinon-chai@3.7.0 wants chai@">=2.1.2 <6", the tree has chai@5.1.1 via
chai-as-promised), so the test suite was not run here.

🤖 Generated with Claude Code