fix(chat): decodeMultipartFilename 正则里混入裸 NUL 字节

## 问题

`apps/api/src/interface/controllers/chat-attachment.controller.ts` 里
`decodeMultipartFilename()` 函数的正则字符类混入了一个原始 NUL 字节
(U+0000)，本应是空格字符 " "：

原意：`/[^ -ÿ]/`（空格到 ÿ 的可打印 latin1 范围）
实际：第一个边界是裸 `\x00`

用 `python3 -c "open('...','rb').read().count(b'\x00')"` 可确认。

## 影响

- git 把该文件当作二进制文件处理（`git diff` 显示 `Bin ... bytes` 而非
逐行 diff），review/blame 体验变差。
- 行为上无害：NUL 到 0xFF 与空格到 0xFF 在"检测非 latin1 字符"这个用途上
结果相同，`attachment-upload.test.ts` 的中文文件名 mojibake 用例仍然通过。
- 纯粹是历史遗留的编码事故，不是最近改动引入的。

## 方案

把字符类改写成显式 Unicode 转义 `/[^ -ÿ]/`，避免源文件里
再混入不可见控制字符。跑 `attachment-upload.test.ts` 确认 mojibake 用例仍绿。

分支：`worker/usamshen-hygiene-decode-filename-nul`

Start in apps/api/src/interface/controllers/chat-attachment.controller.ts and inspect decodeMultipartFilename(), then use the issue’s Python byte-count command to confirm the raw NUL. Replace the invisible character with the stated printable Latin-1 range and run attachment-upload.test.ts, including the Chinese filename mojibake case, to verify the behavior remains green.

Written by the indexing model from the issue text.