Firewall backend selection logic

## Description

The firewall detection logic incorrectly tries to infer which iptables backend is active by checking which backend contains rules. This approach is fundamentally flawed because **iptables-nft and iptables-legacy share the same kernel netfilter ruleset**.

## Steps to Reproduce

1. System configured with `update-alternatives` to use iptables-nft as default
2. System has rules from multiple sources (e.g., Kubernetes using iptables-nft, Multipass using iptables-legacy)
3. Observe that Multipass uses iptables-legacy despite system preference being iptables-nft

## Expected Behavior

Multipass should respect the system's default iptables configuration and use the backend that `/usr/sbin/iptables` points to.

## Root Cause

The current `detect_firewall()` function tries to determine the active backend by checking if rules exist in each backend. This fails on hybrid systems because both backends share the same ruleset - rules added via one backend appear in both.

## The Fix

The fix implements a two-level detection strategy:
1. **Primary**: Check `/usr/sbin/iptables` symlink to determine system preference
2. **Fallback**: Only use rule presence detection when system config is unavailable

This properly handles systems where:
- Multiple tools use different iptables backends
- Both backends have rules present
- System configuration indicates a preference

## Related Files

- `src/platform/backends/qemu/linux/firewall_config.cpp`

See PR #5114 for the implementation.

Read src/platform/backends/qemu/linux/firewall_config.cpp and inspect the current detect_firewall() logic, then compare the proposed behavior with PR #5114. Done means backend selection follows /usr/sbin/iptables when system configuration is available and only falls back to rule detection when it is not.

Written by the indexing model from the issue text.