[Lyrex]

fix(riven): read the weapon name from the panel that states it

Symptom. On a Kuva Nukor reroll screen the weapon name comes back empty. On
other Kuva and Tenet screens it comes back as the base weapon, so a Kuva Nukor
riven is reported and graded as an ordinary Nukor.

Root cause: the name is below every crop that looks for it. ocr_riven_screen
currently runs two passes:

pass	rect	used for
full frame	0.0-1.0 x 0.0-0.82	INVENTORY/MODS + FITS IN markers, weapon fallback
card column	0.20-0.65 x 0.28-0.82	stat parsing

The weapon name is printed under the icon in the "FITS IN" panel, at about 86% of
frame height. Both passes stop at 82%. The only crop in the file that reaches the
panel at all is riven_screen_visible's 0.73-1.0 x 0.30-0.80, which stops at 80%
and is not used for extraction anyway. So the name is on screen and nothing reads it.

The current extraction takes the line after FITS IN out of the full-frame text.
When the panel is unreadable it falls through to the mod title above the card, and
the mod title is a different weapon. "Nukor Crita-hexapha" resolves to the ordinary
Nukor, a different disposition from the Kuva Nukor it is actually for, with nothing
telling the user a substitution happened.

Fix.

1. A third OCR pass over the same capture, 0.73-1.0 x 0.30-0.95. That is the rect
   riven_screen_visible already uses, carried to 95% so it covers the name. Raw
   OCR, as riven_screen_visible does, because the panel is white on dark and your
   own comment there says it reads fine unpreprocessed. No extra capture: the
   pixels are already in hand.
2. The weapon comes from the panel first, mod title as fallback.
3. An unlisted weapon is still the right weapon. The grading sheet is a curated
   list, not a weapon index. It has "kuva bramma" but not "kuva nukor", so the
   panel name is used whether or not the database knows it. That costs the roll
   analysis for unlisted weapons (analyze_riven returns nothing for an unknown
   key, which the UI already renders as a null analysis) and buys never grading one
   weapon's roll against another's disposition.
4. Panel picking needs a rule, since the crop is mostly icon and border debris:
   a candidate is a line of at least 4 letters that is not one of the panel's own
   buttons. The name sits below FITS IN and above SHOW RANKED, so the last
   candidate wins.
5. The marker test compares with spaces removed. At this size an engine can close
   the word gap and report FITSIN, which contains("fits in") never matched.

Tested. Two tests: panel_weapon_candidates against verbatim panel OCR from
three reroll screens (including one panel that is pure debris and must name
nothing), and the space-stripped marker match.

Verification, please read this part before merging.

This is the change in the batch I am least able to stand behind on your platform,
and I would rather say so than have you find out.

• The two new helpers are pure string functions. I extracted them into a scratch
  crate and ran their tests on Linux: both pass. That covers the picking logic.
• The 0.95 crop bound was measured through Tesseract on Linux, on three
  screenshots. It has never been through WinRT OCR. The geometry argument is
  engine-independent, since the name is at about 86% of frame height whatever reads
  it, and 86% is past 82%, so I am confident the old crops cannot see it. I am not
  able to confirm WinRT reads it cleanly at 95%, or that the extra 15% of panel
  height does not drag in something that confuses it.
• The FITSIN observation is Tesseract-specific. Your contains("fits in")
  presumably works today on WinRT, so item 5 is tolerance rather than a fix on your
  platform. It is one replace(' ', "") and it cannot reject anything the old test
  accepted, but it is honest to say it is there because of my engine, not yours.
• lib.rs does not compile on Linux (Win32 memory APIs), so this has not been
  built by the real toolchain.

So there is a question in here for you: can someone confirm the weapon name reads
at a 0.95 bound through the Windows OCR path? If it does not, the geometry is
still the right diagnosis and only the bound needs tuning.

If you reimplement this rather than taking the commit, the load-bearing parts are:

1. The panel crop must extend past 82%, and it must be its own pass. Widening the
   full-frame pass instead would push the panel's text into the stat parser, which
   is exactly why the card-column pass excludes the right panel today.
2. The panel must be preferred over the mod title, not merged with it. Falling
   back to the title on a database miss is the bug: it silently substitutes a
   different weapon on a different disposition.
3. An unrecognised panel name must still be reported. Requiring a database hit
   reintroduces the substitution for every weapon the curated sheet omits.
4. Take the last candidate, not the first. The name sits below the label and
   above the buttons, so first-match lands on panel chrome.

[Lyrex]

thank you for integrating the PRs into the main repo! verified it on/against the linux branch, and everything is working well!