Fix #2096: harden NamedLocksTrackingFileManagerTest against CI load (#2098)

## Summary

- Increase per-operation lock timeout from 5s → 30s in `NamedLocksTrackingFileManagerTest`
- Add proper `FileLockNamedLockFactory.shutdown()` in `@AfterEach` to close idle channels and lock files

## Root cause analysis

The test runs 4 threads × 1000 iterations of concurrent `read(shared)` + `update(exclusive)` against the same file, exercising the full `FileLockNamedLock` contention path. Each exclusive lock attempt retries with a 100ms sleep between attempts.

The 5-second timeout was **already bumped from 1s → 5s** in [194128ae](https://github.com/apache/maven-resolver/commit/194128ae) ("Seems timeout of 1s is not enough?"). Recent performance optimizations (#1937) changed the lock acquisition timing characteristics:

1. The **lock-free fast path** in `NamedLockFactorySupport.getLockAndRefTrack()` makes `getLock()` much faster, allowing threads to re-acquire locks more rapidly and increasing file lock contention
2. The **idle channel pool** in `FileLockNamedLockFactory` (from the FD leak fix) adds a small amount of work inside `locks.compute()`, marginally extending the time the ConcurrentHashMap bucket lock is held

Neither change introduces a concurrency bug — the channel management is correctly serialized by `locks.compute()` bucket locks, and the `tryIncRef` CAS sentinel correctly prevents revival of destroyed holders. However, on loaded CI machines, the changed timing profile can push borderline operations past the 5s threshold.

The factory was also never shut down after tests, leaking idle `FileChannel` instances.