Let the narrower behavior win where both landed

[zmaril]

Follow-up to the merged idiom work, from measuring precision off the 13-file
corpus for the first time.

The problem

Option::and_then is match self { Some(x) => f(x), None => None }. The hole
swallows whatever a narrower way of consuming an Option puts there, so it
matches map, filter and ok_or and says less about each than they say about
themselves. On clippy's manual_map test it landed on fifteen of the same
lines Option::map did — fifteen second, weaker findings on code that already
had a better one.

This is the failure mode notes/todo.txt records twice, most recently as
Option::is_none_or firing 1,390 times across five hundred crates: "both were
correct, both subsumed every narrower behavior".

Why is_reportable does not catch it

It is the existing answer to a behavior that describes too much, and it cannot
reach this one. and_then names two variants, so it clears the anchor floor
while still subsuming everything narrower. What separates the two is not how
much either names on its own but how they stand to each other — and a form
used as a pattern already answers that. A form that matches another behavior's
form accepts everywhere that one does and elsewhere besides.

Per placement, not per pack

The part worth reviewing. Being broader is not being wrong: code that really
does reimplement and_then should hear about it, and a pack-wide rule would
lose that. It is only grounds for standing aside where something narrower has
already landed. tests/subsumption.rs pins both directions.

Measured

corpus	before	after
13-file clippy corpus	26/201, 36 reported, 36/36 on-target	unchanged
wider 18-lint manual_* sample	59 reported, 10 found, 43 off-target	44 reported, 10 found, 28 off-target

Nothing that was right was removed. On-target share goes from 16/59 to 16/44.

The 28 that remain are not this problem:

• 11 are manual_unwrap_or_default reporting unwrap_or — correct, just
  less sharp than the API clippy names
• 11 are manual_filter reporting and_then because Option::filter
  derives no behavior at all. Nothing narrower exists to win. That is a recall
  gap, and a separate piece of work.

Also worth knowing

The measure/packs/std pack is stale. Re-derived with current code it is
589 behaviors rather than 483, and Iterator::filter_map comes out as
(sift f0 v1 (call f1 v1)) rather than the unlifted Sequence[Traverse, None]
it is stored as. Re-deriving does not move the score — that fresh form is
size 5 against MINIMUM_REPORTABLE_SIZE 6 with 0 anchors, so it is correctly
refused — but anyone reading that pack should know it predates the one-step lift.

358 tests, clippy clean.