## Before you submit

> **New feature?** Please open an issue first and get approval from the maintainers before writing any code.
> PRs that introduce features without a prior discussion will be closed.
>
> **Used AI assistance?** That's fine - but make sure you've read and understood every line of the diff
> before submitting. PRs that show no sign of self-review will be closed without detailed feedback.
>
> **Keep it focused.** One thing per PR. Don't bundle a bug fix with a refactor or unrelated cleanup.
> If it's not ready, open it as a draft instead.

---

## What does this PR do?

<!--
A short summary of the change and why it's needed.
Link at least one issue using a GitHub closing keyword, for example:
- Closes #123
- Fixes: #123
- RESOLVED owner/repo#123
-->

Closes #

## How did you test this?

<!-- Tell us what you actually did to verify this works. What did you run? What did you click through?
     A quick note like "spun up Docker, added a book, confirmed it shows in the library" is perfect.
     This helps us review with confidence and speeds up the merge. -->

## Screenshots

<!-- If this touches the UI, please include a before/after screenshot or a short screen recording.
     You can drag and drop images directly here. -->

## Anything non-obvious in the diff?

<!-- Did you make any tricky decisions or trade-offs? Anything you'd want a reviewer to pay
     extra attention to? This is your chance to guide the review. -->

## Checklist

- [ ] I've read through my own diff
- [ ] This PR was discussed in an issue and has maintainer approval (for new features)
- [ ] Lint and tests pass locally
- [ ] No unintended files included (build artifacts, `.env`, personal configs)