fix(files): honour the escape flag in every filename validity message

[torvalstrom]

getFilenameValidity() documents its second parameter as

@param escape Escape the matched string in the error (only set when used in HTML)

but only the forbidden-character branch passes it on. The reserved-name and forbidden-extension branches hardcode escape: false, so a caller that asks for escaping — because it renders the result as HTML — gets the matched segment back raw.

Not a vulnerability, to be clear

The segments those two branches report come from server configuration (forbidden_filenames, forbidden_filename_extensions), not from anything an unprivileged user controls, and all three call sites in the tree pass escape = false today. So there is nothing to exploit. What is worth fixing is a documented parameter quietly not doing what it says, before a caller starts relying on it.

Why the existing tests could not catch it

The forbidden-character check runs first, so any name containing <, > or " is rejected there — in the one branch that already honoured the flag. That is why the escape option block only ever exercised that path.

The two new tests use & instead: the translation layer escapes it, but it is not a forbidden filename character, so validation falls through to the reserved-name and extension branches.

Before and after

Same tests, against the unmodified source:

Received: ""a&b" is a reserved name and not allowed for filenames."
Received: "".a&b" is not an allowed filetype."
Tests  2 failed | 16 passed (18)

and with the change:

Tests  18 passed (18)

npx vitest run apps/files/src/ is green overall — 27 files, 198 tests — and npx eslint is clean on both changed files.

AI (if applicable)

• The content of this PR was partly or fully generated using AI

Written with Claude Code (claude-opus-5); every change was reviewed, built and tested by me before opening the PR, and the measurements quoted above are real command output rather than model claims. Commits carry Assisted-by: ClaudeCode:claude-opus-5.

[skjnldsv]

thanks @torvalstrom ! Quick note, you need to clarify whether you used AI or not in the OR bidy as well as the commit comment with an assisted-by line. See our github template

e.g: Assisted-by: ClaudeCode:claude-fable-5-1

[torvalstrom]

Thanks for the pointer — done, and applied to all five of my open PRs rather than just this one:

• fix(auth): accept a percent-encoded login name for app password logins #64324, fix(l10n): stop double-escaping the instance name in settings text #64369, fix(user_ldap): show %uid instead of %%uid in the login filter hint #64370, fix(files): honour the escape flag in every filename validity message #64374
• feat(editor): warn when an event overlaps one already in the calendar calendar#8945

Each commit now carries Assisted-by: ClaudeCode:claude-opus-5 above the sign-off, and each PR body has the AI section from the template with the box ticked. DCO is green again after the amend.

Apologies for making you ask — I had read the template's checklist but skipped straight past the AI section at the bottom.