[fix][broker] Stop reporting a deliberate ownership release as an expired resource lock - #26533

Motivation

ResourceLockImpl.release() completes the lock's expiry future, so OwnershipCache's lock-expiry
listener also runs at the tail of every deliberate release: every bundle unload, the split cleanup,
and shutdown. The listener logs Resource lock has expired at INFO unconditionally, so a routine
unload emits a line that reads like a lost metadata session. Operators get one false hit per unload,
which buries the cases that line is meant to surface — a lost session or a failed revalidation.

Modifications

Both removeOwnership overloads take the lock out of locallyAcquiredLocks before calling
release(), so the lock is still registered when the listener runs only if it died on its own. The
INFO line is now gated on the two-arg locallyAcquiredLocks.remove returning true; a deliberate
release, or a stale listener whose generation has already been replaced, logs at DEBUG instead.
Nothing outside logging changes.

Verifying this change

• Make sure that the change passes the CI checks.

This change added tests and can be verified as follows:

• Added OwnershipCacheTest.testReleasingOwnershipDoesNotReportTheLockAsExpired: a normal
  removeOwnership must not produce an INFO Resource lock has expired. Fails before the change.
• Added OwnershipCacheTest.testLockDyingOutsideOfReleaseIsReportedAsExpired: a lock that dies
  without going through removeOwnership is still reported at INFO, so the line cannot be dropped
  instead of gated.
• Both use the existing TestLogAppender. OwnershipCacheTest (20), NamespaceUnloadingTest,
  NamespaceOwnershipListenerTest and the unload / split cases of NamespaceServiceTest pass
  locally; ./gradlew quickCheck is clean.

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment