docs(guidelines): correct the max_by_key tie direction and record the decline's cost

[inureyes]

docs(guidelines): correct the max_by_key tie direction and record the decline's cost

Two corrections to the HashMap Iteration Order section added in #1290.

The order-sensitive consumer list said min_by_key and max_by_key "both
return the FIRST extremum". That is wrong for the max side and it is wrong in a
way that misleads a fix: min_by_key and min_by return the first minimum,
while max_by_key and max_by return the last maximum. Verified with rustc -O over [(1, 5), (2, 5), (3, 5)]: max yields (3, 5) and min yields
(1, 5). The practical consequence is that a tie component has to face the
right direction for the call being fixed, and two arms of one policy can need
opposite directions, which is exactly the case in #1293.

The enforcement block recorded why two static-check candidates were declined but
recorded only the arguments in favour of declining. It now also records what the
decision has cost: #1293 is an eighth instance whose tie is reachable, and
neither candidate flagged it, because its receiver is a cross-module accessor
method rather than a literal .values() on a locally declared map. That is the
same limitation the block already describes for #1277, so the section was
predicting its own miss without saying so.

Documentation only, no Rust changed.