filesystem: overlapping roots refreshes can apply out of order and undo a revocation #5097

Problem

The filesystem server handles each notifications/roots/list_changed by calling listRoots() and applying the answer, with no ordering between refreshes. The SDK dispatches notification handlers without waiting for earlier ones, so when a client sends two roots/list_changed in quick succession, the two roots/list responses can resolve out of order, and the older answer is applied last. The same applies between the initial roots/list (after initialized) and a roots/list_changed that arrives while it is still outstanding.

Since #5094 a withdrawn root revokes access, so the stale-answer case matters more: a newer empty (or all-invalid) answer can revoke access and then an older answer that still listed the root can restore it.

• Pre-existing: out-of-order application already affected valid-to-valid updates on main / 2026.8.31.
• Reported by Copilot on v1.0.0: cherry-pick the #5094 roots revocation fix onto the release branch #5096 (thread r4236797364), the release-branch cherry-pick of the filesystem: a roots update with no valid roots keeps the previous allowed directories #5094 fix.

Expected

Roots refreshes take effect in the order the client announced them: tag each refresh (a generation counter incremented per notification and for the initial load) and discard an answer that is no longer the latest; or serialize refreshes behind each other and behind the initial load. A protocol-level regression test with overlapping updates whose answers resolve out of order (delay the first answer).