filesystem: tool calls use the old allow-list while a roots refresh is pending

Finding: In the MCP filesystem server (modelcontextprotocol/servers), an issue reports that during a pending roots refresh triggered by a runtime notifications/roots/list_changed, tool calls such as list_directory are still authorized against the previous allow-list. A client that has withdrawn a root can therefore still see it read or modified until it answers roots/list. The issue author says the problem was reported by Copilot on the v1.0.0 merge PR #5090 (thread r4237017991); that review thread was not examined, so this is the issue author's statement only (source: https://github.com/modelcontextprotocol/servers/issues/5101). Reported scenario (external report, not reproduced by KFA): a Roots client exposes one root and list_directory succeeds. The client then withdraws the root and sends roots/list_changed but answers the server's roots/list slowly. A list_directory call sent during that wait still succeeds against the old allow-list. The issue body says the initial roots load (#3204) and a refresh that overtakes it (#5097) already make tool calls wait, but an ordinary runtime refresh did not (https://github.com/modelcontextprotocol/servers/issues/5101). Expected behavior stated in the issue: every roots refresh acts as a barrier. A tool call that arrives while a refresh is pending waits for it, and for any newer refresh that overtakes it, then runs against the new result. If the refresh fails, waiting calls proceed against the current allow-list, as before (same issue). Fix status: a MEMBER comment says the issue is fixed on v2/main by #5102 and on release branch v2/release/1.0.0 by #5103, and that it ships in v1.0.0 (https://github.com/modelcontextprotocol/servers/issues/5101#issuecomment-6095943643). This is the maintainer's statement only. The PRs and any release artifact were not in the supplied sources, so merge state, diff content and the actual shipped release are unverified. Closure of the issue alone does not prove the fix. Diagnosis implication: the described revocation lag may affect any filesystem server build that lacks the changes from #5102 and #5103, if you rely on roots to revoke access. Which released versions or builds are affected is unknown from the source. No workaround was reported. This record is an external report with a maintainer-reported fix; KFA did not reproduce it or verify the fix.