Fix previousKey returning the predecessor and throwing for keys not in the map

[lenamonj]

previousKey carries the defect #728 fixed in nextKey. AbstractSortedMapDecorator.previousKey returns headMap(key).lastKey() without checking that key is present, so an absent key inside the range returns its predecessor and a key outside a range-restricted view throws IllegalArgumentException; DualTreeBidiMap.previousKey fails the same way. OrderedMap documents null for a key with no match, and every other previousKey in the library returns it.

Return null when the map does not contain key, and use NavigableMap.lowerKey when the decorated map offers it, mirroring #728 line for line.

Tests: both ordered-map conformance suites now assert the absent-key case on a full map, plus four explicit tests; red on master and green with the change. Default Maven goal green.

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute? Claude (Anthropic) found the defect and drafted the fix and tests; I reviewed them, reproduced the failure on a fresh clone of master, and ran the default Maven goal.
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

[lenamonj]

Superseded by #738, which Gary asked for on #728; closing.