Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@booklore-api/src/main/java/org/booklore/service/reader/EpubReaderService.java`:
- Around line 61-67: Change createDocumentBuilder() to declare and throw
ParserConfigurationException instead of wrapping it in RuntimeException; update
parseXmlEntry(...) and parseEpubWithEncoding(...) signatures to propagate that
checked exception; then modify parseEpubMetadata(...) so the code that
initializes the parser (calls to
createDocumentBuilder/parseXmlEntry/parseEpubWithEncoding) is performed outside
or before the charset-retry loop and any ParserConfigurationException is caught
and rethrown or handled immediately (not treated as an encoding failure), while
the charset retry loop only catches IO/encoding-related exceptions.

In `@CONTRIBUTING.md`:
- Around line 234-244: The docker run example mixes host networking and a port
mapping which is redundant: remove the -p 6060:6060 token from the docker run
command (or alternatively remove --network host if you prefer bridge networking
and keep -p, remembering to update the datasource URL away from localhost);
update the example so it uses either "--network host" alone or "-p 6060:6060"
without "--network host" so readers aren’t confused.

---

Outside diff comments:
In
`@booklore-api/src/main/java/org/booklore/service/user/DefaultSettingInitializer.java`:
- Around line 37-51: The code removes the per-user lock from userLocks after
unlocking, creating a race where waiting threads may use a stale lock; keep the
lock in the map instead of removing it. Modify DefaultSettingInitializer by
deleting the userLocks.remove(bookLoreUser.getId()) call in the finally block
(leaving Lock lock = userLocks.computeIfAbsent(...) and
lock.lock()/lock.unlock() as-is) so locks remain cached per userId; if desired
later, implement a reference-counted eviction, but for now simply stop removing
the lock to fix the race.

---

Nitpick comments:
In `@booklore-api/src/main/resources/application.yaml`:
- Around line 34-36: Reduce risk of DB contention by enabling HikariCP metrics
and logging so you can monitor connection wait times when using virtual threads
(you've set threads.max and threads.min-spare low); specifically, enable Hikari
metrics for the datasource (reference spring.datasource.hikari.maximum-pool-size
and the HikariDataSource/HikariPoolMXBean APIs), register MBeans or wire
Micrometer metrics (e.g., register-mbeans / metricsTrackerClassName) and
log/alert on connection waitTime/connectionTimeout and activeConnections; if
metrics show high contention, increase
spring.datasource.hikari.maximum-pool-size or tune connectionTimeout accordingly
and add an alert threshold for wait times.