feat(book): allow deleting an individual tracked file

[trevorswanson]

Summary

Closes #2485.

Add a destructive Delete this file action to each tracked file's More menu on the book detail page. The action is placed below Forget this file, deletes only the selected tracked file, removes its book_files row, refreshes the book state, and records a history event.

The implementation preserves configured-root and cross-book ownership safety checks, keeps audiobook directory-backed entries atomic, and leaves format-level deletion and DB-only forgetting unchanged. Status remains imported when another file for the monitored format survives; an imported book returns to wanted only when the last required file for a monitored format is removed.

Checklist

• Commits signed off with git commit -s — see Sign your work
• Tests added or updated
• docs/DEPLOYMENT.md updated if env vars, config, or upgrade path changed (not applicable)
• Added a changelog fragment under changelog.d/ (not added; maintainer/release process)
• Wiki pages updated if user-facing behaviour changed (not needed for this focused UI action)

Test plan

• go test -count=1 ./internal/api ./internal/importer ./internal/db
• npm test -- --run src/pages/BookDetailPage.test.tsx (62 tests passed)
• npm run lint (0 errors; existing warnings only)
• git diff --check

[codecov]

Codecov Report

❌ Patch coverage is 75.00000% with 16 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/api/books.go	65.78%	9 Missing and 4 partials ⚠️
internal/api/path_safety.go	88.46%	2 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[vavallee]

Tested locally against main and the fail before check holds, ownership and containment are all routed through the same guards as the scoped delete, good.

One thing to fix before merge: deleteTrackedBookFile throws away the skipped result from safeRemoveBookPathExact. When the root check or the other book ownership guard refuses the unlink, we still drop the row, answer 200 and write a history event saying the path was deleted. For a destructive action the response and the history need to say what actually happened. The format scoped delete only records paths it actually removed, so either do the same (put skipped into the event data and the response) or refuse the request when the file was not removed.

Also noting the exact delete never prunes an empty parent folder the way the scoped sweep does. Fine either way, just mention it in the PR if you leave it.