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. Exact affected versions are unknown; the issue was raised against the v1.0.0 merge PR #5090 and the v2 branches (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: if you run a build of the filesystem server from v2 pre-release code that predates these PRs and rely on roots to revoke access, be aware that access revocation may lag until the client's roots/list response arrives. No workaround was reported. This record is an external report with a maintainer-reported fix; KFA did not reproduce it or verify the fix.