tests/baseosmgr: e2e coverage for force-fallback and retry-update

[eriknordmark]

Summary

Adds a new `tests/baseosmgr/` suite with two e2e tests that exercise the two controller-driven knobs in `pkg/pillar/cmd/baseosmgr` that are otherwise reachable only through real partition flips and a real controller round-trip:

Test	Path tested	Failure / drive mode
`force_fallback`	`handleForceFallback` (`forcefallback.go`)	Bumps the global config knob `force.fallback.counter` after a successful upgrade and asserts the device reverts to the captured pre-upgrade version.
`retry_update`	`handleUpdateRetryCounter` + `isImageInErrorState` (`handlebaseos.go`)	Triggers an upgrade, black-holes the controller's IP via in-EVE `iptables` so the post-update test window times out (`BootReasonFallback`), then bumps `RetryUpdateCounter` via `eveimage-update-retry` and asserts the same image succeeds on the second attempt.

These complement the existing `tests/update_eve_image/` suite (which already covers the happy upgrade path + simple revert) and the new `tests/nodeagent/baseos_fallback_*` (#1162, which covers the fallback-on-cloud-disconnect path from nodeagent's perspective).

What's covered (and what isn't)

`force_fallback` exercises `handleForceFallback`'s precondition check
(curr=active, other=unused with non-empty `ShortVersion` — only true after a
prior successful upgrade), the
`/persist/checkpoint/forceFallbackCounter` plumbing, the
`SetOtherPartitionStateUpdating` path, and that nodeagent reacts to the
flip and reboots into the previous image. The version-based assertion
(`cmp` of the post-rollback active version against a captured `old_ver`
file) is unique to this path — only force-fallback can revert
`SwList[0].ShortVersion` to the pre-upgrade value.

`retry_update` exercises the "failed image" branch of
`isImageInErrorState` (curr=active, other=inprogress with a matching
`BaseOsConfig.Activate=true`), the
`SetOtherPartitionStateUpdating` + `saveConfigRetryUpdateCounter` path,
and the second `BootReasonUpdate` cycle that nodeagent issues into the
same partition. The black-hole is removed naturally by the post-fallback
reboot (in-memory iptables rule dies with the previous boot), so the
retry's test window passes against a working controller.

Test plan

• Both tests run locally against a coverage-instrumented EVE under
  QEMU (`ZedVirtual-4G`). (deferred: eden harness is busy)
• CI run on lf-edge/eden's harness.

Per-test runtime estimate (laptop, KVM-accelerated):

• `force_fallback`: ~10–15 min (one full upgrade-then-rollback cycle).
• `retry_update`: ~12–18 min (one failed-attempt cycle + one retry cycle).

Implementation notes

• Capture-then-compare for the version assertion: `force_fallback` runs
  `eden info ... PartitionState:active --tail=1` before the upgrade,
  saves the result to `old_ver`, and after the rollback runs the same
  command again and `cmp`s against `old_ver`. This is more robust than
  asserting `! stdout '$short_version'` because the post-fallback Info
  publish-cadence might still echo a stale pre-reboot sample if the
  assertion fires too early; the `cmp` is exact.
• Idempotency across runs: both tests issue `eveimage-remove` + brief
  wait before `eveimage-update`, so re-running with the same EVE version
  still triggers a fresh update.
• Config-propagation timing: `timer.config.interval=10` shortens
  controller polling so subsequent config pushes (the
  `force.fallback.counter` bump or the `RetryUpdateCounter` bump from
  `eveimage-update-retry`) propagate within ~10s. `timer.deviceinfo.interval=30`
  ensures post-rollback Info publishes promptly so `lim.test` doesn't
  wait 10 min for the next periodic push.
• Black-hole mechanism (retry_update): `eden eve ssh -- iptables -A OUTPUT -d -j DROP`,
  identical to the new `tests/nodeagent/baseos_fallback_blackhole.txt` in
  tests/nodeagent: e2e coverage for reboot paths, restart counter, and disk-space maintenance #1162. Device-model gating is the same (`ZedVirtual-4G` / `VBox` only).
• Suite is not wired into broader workflows — the two tests are
  addressable on their own (`eden.escript.test -test.run TestEdenScripts/force_fallback -testdata tests/baseosmgr/testdata/`).
  Folding them into a broader `smoke` / `eve-upgrade` workflow is a
  follow-up.

Suite structure

```
tests/baseosmgr/
├── Makefile (boilerplate matching tests/nodeagent/)
├── eden-config.yml
├── eden.baseosmgr.tests.txt
└── testdata/
├── force_fallback.txt
└── retry_update.txt
```

Why draft

Has not been run end-to-end yet (eden harness was busy at write time);
will be exercised on `ZedVirtual-4G` / `VBox` before marking ready.

The companion eve-side PRs that the unit-test side of this work is in:

• docs(baseosmgr): add architecture document eve#5921 — `docs(baseosmgr): add architecture document`.
• baseosmgr: add Phase-1 unit tests + pathConfig seam eve#5922 — `baseosmgr: add Phase-1 unit tests + pathConfig seam`.
• baseosmgr: Phase 2 — Zboot/kubeapi/HVType seams + tests eve#5923 — `baseosmgr: Phase 2 — Zboot/kubeapi/HVType seams + tests`
  (lifts package coverage from 0 % to ~75 %).

This PR is independent of those (it only touches eden), but the same
review eyes apply to the design.