>>525 , >>526
回答遅くなって申し訳ありません。知り合いに相談しながら解決を試みたのですが結局うまく行かずでした。
まず名前解決についてですが、Androidの名前解決は基本的にDNSなので、一般的な家庭であれば、ルーターがDNSになっているが、
ルーター側でPC名を解決できる機能を持っていないとAndroidからホスト名のみでの解決はできない。
私の家のルーター(HGW)はその機能がないため、DNSによるローカルネットワーク内のPCの名前解決はできない。
自宅内にDNSサーバーを立ち上げてみたりしたのですが、どうにもHGWが悪さをしてDNSによる名前解決に至らなかった。
そのため、現在はVirtual hostというF-Droidアプリを入れて、hostsによる直接的な解決を行っている
自宅の中ではVirtual host, 外ではtailscaleとVPNを切り替えることでホスト名を変更しなくてもとりあえずは運用できています。
--
知り合い曰く、jCIFS-ngによる名前解決の挙動が原因ではないか？という意見がありました。
・jCIFS-ngは、ホスト名での接続要求を受けた際に、まずDNSによる名前解決を試みる
・自宅のルーターは、外部のDNSサーバーへの問い合わせは中継するが、ローカルネットワーク内のPCのホスト名をDNSとして解決する機能は持っていない
・そのため、jCIFS-ngがDNSに問い合わせても、そのホスト名は解決できない。
　この際、jCIFS-ngはDNS解決が失敗したと判断するまでに、設定されたタイムアウト時間（おそらく30秒程度）を待ってしまう
・Tailscale経由の場合、Tailscale独自のDNSがホスト名を瞬時に解決してくれるため、このDNSタイムアウトが発生せず、すぐに接続に進める
・DNS解決がタイムアウトした後、jCIFS-ngはLLMNR (Link-Local Multicast Name Resolution) や
　NetBIOSブロードキャストといったローカルネットワークの名前解決方法にフォールバックする
・SMB3 → SMB2 → SMB1の順に試行するようになったとのことですが、これは名前解決が成功し、IPアドレスが判明した後に始まるプロセスなので、
　プロトコルネゴシエーション自体が直接の原因ではなく、やはり名前解決がボトルネックではないか？
とのことでした。

jCIFS-ngには、名前解決の順序やタイムアウト値を制御するプロパティがあるそうで、例えば、DNSによる解決を試みる前にLLMNRやNetBIOSを優先させたり、
DNSのタイムアウト値を短く設定したりすることで、遅延を回避できるかもしれない、との意見ももらったので、
jcifs.resolveOrderプロパティを[LMHOSTS,WINS,BCAST,DNS]としてみたりしてビルドを行ってみたのですが、結局変化はありませんでした。
この辺詳しい方がいたらぜひフォローをお願いしたいです。