stale zfs_member detection logic leads to spurious ZTS failure (e.g., migration/setup)

### System information Type | Version/Name --- | --- Distribution Name | debian Distribution Version | unstable (forky) Kernel Version | 6.12.85+deb13-amd64 Architecture | amd64 OpenZFS Version | 2.4.1 ### Describe the problem you're observing During a full ZTS run, I get ``` Test: /usr/share/zfs/zfs-tests/tests/functional/migration/setup (run as root) [00:00] [FAIL] ``` Re-running just the `migration/*` tests does not result in any ZTS failures. ### Describe how to reproduce the problem ``` truncate -s 4096M /tmp/a.dev losetup /dev/loop0 /tmp/a.dev zpool create -f sillypool /dev/loop0 zpool destroy sillypool mke2fs /dev/loop0 && mount /dev/loop0 /mnt ``` Notice, critically, that you have to run the mount *immediately* after the mke2fs. If you wait more than about 10 or 20 ms, (presumably) the kernel picks up the removal of the zfs_member from /dev/loop0 ### Include any warning/errors/backtraces from the system logs Nothing interesting. The only log entries are: ``` nfsrahead[1928305]: skipping non-NFS device zfs-16471 systemd[1]: sillypool.mount: Deactivated successfully. ``` ### More thoughts ~I cannot seem to reproduce this "by hand." I.e., just creating a same-sized loopback device, creating a pool using it, destroying it, and creating an ext2 filesystem on it doesn't leave the zfs_member label on it. Moreover, I don't understand how, after clearly discarding all blocks, there could still be a leftover label (?!?).~ ~Maybe an old pool from a previous run (`luks/luks_sanity` is the last one ran in this case) is still somehow doing something, and it somehow re-writes the label after clearing it?~ ~Of course (it would never be that easy), just running luks_sanity and migration immediately afterwards does not appear to reproduce the ZTS failure.~ Should we just stick a sleep 0.5 in the newfs macro?