WiFiContainer.start() silently reuses stale fixture config when the container is already running

Follow-up from review discussion on project-chip/certification-tool-backend#370: https://github.com/project-chip/certification-tool-backend/pull/370#discussion_r4026167335

In test_collections/matter/sdk_tests/support/wifi_container.py, WiFiContainer.start():

if self.is_running():
    logger.warning(
        "Wi-Fi fixture container is already running for " + self.__docker_image
    )
    return False

self.__load_config(config)
...

When is_running() is True, start() returns False without ever calling __load_config. Both call sites in PythonTestSuite.setup() discard the return value, so the current suite silently keeps running against whatever interfaces/docker_image a previous suite configured, with no error surfaced anywhere.

This state is reachable in practice: self.__container (the singleton's tracked container) only goes back to None via destroy(), which is the last line of PythonTestSuite.cleanup(), after sdk_container.destroy() and border_router.destroy_device() — neither of which is guarded by try/except (unlike the admin_storage capture step right above them, which is explicitly wrapped "so don't block container/border-router teardown"). Both of those do real docker calls (exec, container removal) that can genuinely fail transiently. If either raises, wifi_container.destroy() never runs, and the fixture container/singleton state leaks into the next suite that requests it.

Since Test Harness backends normally stay up across multiple sequential runs, this isn't just a unit-test corner case. Because it fails silently rather than erroring, the DUT could end up exercised against a stale AP/station config with no indication to the operator — a worse failure mode for a certification tool than a loud crash, since it can produce a misleading pass/fail verdict instead of an obvious error.

Suggested fix: raise (or otherwise surface) a WiFiContainerError in start() when the fixture is already running instead of silently returning False, and/or guard the sdk_container/border_router teardown steps in cleanup() so wifi_container.destroy() is guaranteed to run even if an earlier step throws.