ID mapping doesn't work for files, container uses same UIDs/GIDs as host

Hello,
when I create a new container, all files in that container use the exact same UIDs and GIDs as the host, even when I enable idmap isolation:

# incus storage list
+---------+--------+--------------------------------------+-------------+---------+---------+
|  NAME   | DRIVER |                SOURCE                | DESCRIPTION | USED BY |  STATE  |
+---------+--------+--------------------------------------+-------------+---------+---------+
| default | dir    | /var/lib/incus/storage-pools/default |             | 10      | CREATED |
+---------+--------+--------------------------------------+-------------+---------+---------+

# cat /etc/subuid
incus:65536:1000000000
root:65536:1000000000

# cat /etc/subgid
incus:65536:1000000000
root:65536:1000000000

# incus init images:debian/12 test-new
Creating test-new
Retrieving image: Unpack: 100% (1.12GB/s)

# incus config set test-new security.idmap.isolated=true

# incus start test-new

# incus exec test-new bash
root@test-new:~# touch foo
root@test-new:~# ls -l foo
-rw-r--r-- 1 root   root 0 Jun 11 22:16 foo
root@test-new:~# 
exit

# ls -l /var/lib/incus/storage-pools/default/containers/test-new/rootfs/root/
total 0
-rw-r--r-- 1 root   root 0 Jun 11 22:16 foo

# incus config show test-new
architecture: x86_64
config:
  image.architecture: amd64
  image.description: Debian bookworm amd64 (20240611_05:24)
  image.os: Debian
  image.release: bookworm
  image.serial: "20240611_05:24"
  image.type: squashfs
  image.variant: default
  security.idmap.isolated: "true"
  volatile.base_image: d02788aeece968be5715583bc59c3d2931d69010b68dbdce531924d1721febe8
  volatile.cloud-init.instance-id: 6f4cf812-d741-4f53-87a5-98ab20328b8b
  volatile.eth0.host_name: vethca4089a2
  volatile.eth0.hwaddr: 00:16:3e:f1:bc:a7
  volatile.idmap.base: "262144"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":262144,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":262144,"Nsid":0,"Maprange":65536}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":262144,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":262144,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[]'
  volatile.last_state.power: RUNNING
  volatile.last_state.ready: "false"
  volatile.uuid: 4a7357d0-d9b0-45c6-a7b7-216bbf6546ce
  volatile.uuid.generation: 4a7357d0-d9b0-45c6-a7b7-216bbf6546ce
devices: {}
ephemeral: false
profiles:
- default
stateful: false
description: ""

#

As you can see, the file foo belongs to root in the container, but also in the host filesystem.

Even stranger: for already existing containers, everything works as expected:

# incus exec nas bash
root@nas:~# touch foo
root@nas:~# ls -l foo
-rw-r--r-- 1 root root 0 Jun 12 07:31 foo
root@nas:~# 
exit

# ls -l /var/lib/incus/storage-pools/default/containers/nas/rootfs/root/foo  
-rw-r--r-- 1 131072 131072 0 Jun 12 09:31 /var/lib/incus/storage-pools/default/containers/nas/rootfs/root/foo

Here, the file foo doesn’t belong to root on the host fs, as expected.

This behaviour started on LXD after upgrading from Debian 11 to 12 and is still present now on Incus.

What am I doing wrong?