fix(garm): sync app status with unit status

[cbartz]

What this PR does

Routes the garm charm's own status writes through the base class's update_app_and_unit_status() instead of assigning self.unit.status directly, so the leader's application status stays in sync with the unit status.

Why we need it

The charm set self.unit.status directly on its readiness gates and in _reconcile_runners() — a unit-only write. Only update_app_and_unit_status() sets the leader's self.app.status, and restart()'s config-unchanged fast path returns before super().restart() ever calls it. So in steady state the application status was never refreshed and froze on a stale value — observed in production as waiting "Waiting for pebble ready" on the App line while the unit was active and healthy.

Test plan: garm tox -e unit (185 passed), including two new tests (confirmed failing before the fix) covering the _reconcile_runners success path and a restart() readiness gate; lint, static (pyright), fmt clean.

Review focus: the six converted status writes (three readiness gates in restart(), three in _reconcile_runners()). No behaviour change beyond additionally setting the app status on the leader. No breaking changes, no new dependencies.

Checklist

• Changes comply with the project's coding standards and guidelines (see CONTRIBUTING.md and STYLE.md)
• CONTRIBUTING.md has been updated upon changes to the contribution/development process (e.g. changes to the way tests are run) — n/a
• Technical author has been assigned to review the PR in case of documentation changes (usually *.md files) — n/a
• I updated docs/changelog.md with user-relevant changes
• I used AI to assist with preparing this PR
• I added or updated tests as needed (unit and integration)
• If integration test modules are used: I updated the workflow configuration — n/a
• If this PR involves a Grafana dashboard: I added a screenshot of the dashboard — n/a
• If this PR involves Terraform: terraform fmt passes and tflint reports no errors — n/a
• If this PR involves Rockcraft: I updated the version — n/a
• If this PR adds/removes a charm, or changes a charm's base class, conventions, tooling, or repo structure: I updated the relevant AGENTS.md — n/a
• If this PR changes .copilot-collections.yaml or .github/instructions/: I re-checked the AGENTS.md "12-factor divergences" guidance — n/a

[Copilot]

Pull request overview

This PR fixes a status-reporting mismatch in the garm charm by routing status updates through the shared update_app_and_unit_status() helper, ensuring the leader’s application status is refreshed alongside the unit status (preventing stale app-level status in steady-state fast paths).

Changes:

• Converted key garm readiness-gate status writes in restart() to use update_app_and_unit_status() so the leader updates app.status as well as unit.status.
• Converted _reconcile_runners() success/failure status writes to use update_app_and_unit_status() for consistent app/unit status updates.
• Added unit tests covering the previously failing scenarios where app status could remain stale after _reconcile_runners() and a restart() readiness gate.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
docs/changelog.md	Documents the user-visible fix to prevent stale application status for the garm charm.
charms/garm/src/charm.py	Routes six status writes through update_app_and_unit_status() in restart() and _reconcile_runners().
charms/garm/tests/unit/test_charm.py	Adds tests that reproduce and prevent regressions of stale app status on the leader.