(Eu vou fazer isso uma resposta e adicionar a ele, mesmo que eu não tenha uma solução pronta. É muito estranho nos comentários.)
O problema não é udev , então "debugging udev" não ajudará. udev apenas reage ao sinal vindo do .408114 do kernel.
Supondo que não há outras mensagens em dmesg do que você mostrou (o que significa "nenhuma", não "nenhuma que você esteja relacionada"; caso contrário, edite a pergunta com a parte antes e depois do snippet), nós sabemos é que o kernel tenta enviar comandos para o relógio inteligente para descobrir mais sobre o dispositivo de armazenamento, e ambos (proteção contra gravação e cache) falham. Depois disso, o kernel possivelmente faz mais interação e, finalmente, decide que este não é um dispositivo de armazenamento USB, porque não responde ou retorna erros. Assim, o kernel remove-o da camada de armazenamento, envia um sinal para udev e udev faz o que deve e remove os nós do dispositivo. Mesmo se você impedir que udev remova os nós do dispositivo, eles não estarão presentes no nível do kernel, portanto, eles serão inúteis.
O que você pode fazer é usar usbmon para farejar os pacotes USB entre o PC e o smartwatch. wireshark pode interpretar isso. Se você quiser depurar isso, precisará ler como funciona o USB, como funciona o armazenamento USB e como funcionam os comandos SCSI que fazem a camada de armazenamento USB funcionar. Isso pode ou não dar uma pista do que está errado. Os padrões não são difíceis de encontrar com um pouco de googling.
Também é possível que o relógio inteligente barato simplesmente não implemente o padrão de armazenamento USB corretamente, e tenha um driver especial do Windows escrito pelo fabricante que esconde esse fato. Nesse caso, você também pode farejar o tráfego USB no Windows para descobrir como ele funciona, mas você terá que escrever seu próprio kernel do Linux ou o driver do userspace para ele, o que é muito trabalho.