fix: collision names must survive the sanitiser the content view applies

unique_filename produced 'manual (2).pdf'; HouseplanContentView sanitises the
name in the REQUEST too, turning ' (2)' into '_2_', so the file was written and
then 404'd. The same pattern was already in files/migrate, so a rebind that hit
a name collision has been producing dead links. Both use the shared helper now,
with '-2', which round-trips sanitize_filename — asserted.

docs/CHANGELOG.md

@@ -25,7 +25,11 @@
   shared folder, so two of them attaching `manual.pdf` ended up pointing at the
   same physical file. Uploads now take a free name and never overwrite, a new
   icon gets its own staging folder whose files move to the real icon when the
-  save is accepted, and an upload nobody saved is collected an hour later.
+  save is accepted, and an upload nobody saved is collected an hour later. The
+  name a collision falls back to changed from `manual (2).pdf` to `manual-2.pdf`
+  — the old one was sanitised on the way back in, so a renamed attachment was
+  written and then never served (found by the new test, and it applied to
+  rebind collisions before this release too).
 - **Two quick edits can no longer lose the second one (HP-1454-03).** The
   debounce spaced out the starts of a save, not the saves themselves. If one
   took longer than half a second — a busy instance, a slow link — the next edit

docs/CHANGELOG.ru.md

@@ -33,7 +33,11 @@
   один физический файл. Теперь загрузка занимает свободное имя и никогда не
   перезаписывает, новая иконка получает собственную промежуточную папку, файлы
   из которой переезжают к настоящей иконке при принятом сохранении, а загрузка,
-  которую никто не сохранил, убирается через час.
+  которую никто не сохранил, убирается через час. Имя, на которое уходит
+  коллизия, сменилось с `manual (2).pdf` на `manual-2.pdf`: старое санитайзилось
+  на обратном пути, поэтому переименованное вложение записывалось и больше не
+  отдавалось (нашёл новый тест; до этого релиза так же ломались коллизии при
+  перепривязке).
 - **Две быстрые правки больше не теряют вторую (HP-1454-03).** Debounce
   разносил старты сохранения, а не сами сохранения. Если одно длилось дольше
   полусекунды — занятый сервер, медленная связь, — следующая правка уходила с