provider-microk8s test pins a MicroK8s channel whose containerd AppArmor profile blocks container networking

`tests/provider-microk8s/concierge.yaml` pins `channel: 1.31-strict/stable`. On a kernel that mediates the AppArmor `net` class, that channel's containerd denies every container a network socket, and the suite hangs on `microk8s enable metallb:10.64.140.43-10.64.140.49` until something times out.

The chain, from the runner's kernel log:

```
apparmor="DENIED" operation="create" class="net" profile="cri-containerd.apparmor.d"
family="inet" sock_type="stream" requested="create" denied="create"
```

`cri-containerd.apparmor.d` is the default profile containerd applies to containers. The one shipped with the containerd in MicroK8s 1.31 predates AppArmor's `net` mediation and so carries no `network` rules, which on a kernel that does mediate the class means socket creation is denied rather than unmediated. The pods then fail like this:

```
calico-kube-controllers dial tcp 10.152.183.1:443: socket: permission denied
coredns listen tcp :8080: socket: permission denied
metallb controller dial tcp 10.152.183.1:443: socket: permission denied
```

CoreDNS and calico crashloop, the metallb controller crashloops, the speaker never starts (`secret "memberlist" not found`, which is second-order - the addon script doesn't get that far), and `microk8s enable metallb` waits for a rollout that can never complete.

The kernel in my failing case is `6.17.0-1022-azure` on `ubuntu-24.04` with `kernel.apparmor_restrict_unprivileged_userns=1`. The `preset-microk8s` suite passes on the same runner in the same workflow run, enabling the same three addons. It doesn't pin a channel, so it resolves to a newer one and gets a containerd whose profile has the `network` rules.

I've bumped `1.32-strict/stable`, which is the smallest change that works.