docs(log-viewer): say what the row mark actually missed

[lukecotter]

📝 PR Overview

#975 explained the row mark with a mechanism that does not exist: that the renderer de-initialises a row scrolled out of view and rebuilds it, dropping the class. A reader who trusts that comment would expect an ordinary scroll to lose a mark, and would look in the wrong place when the mark misbehaves.

What actually happens: Row.create() is guarded by this.created, Row.initialize() deletes cells but re-uses the element, RowManager.styleRow adds and removes parity classes rather than assigning className, and our renderer only detaches and re-attaches the element. A class on a row element survives scrolling. The gap the declarative mark closes is the first render: a row that has never been on screen has no element, so a sweep of what is rendered cannot reach it.

🛠️ Changes made

• Correct the wantedByHost comment to name the real gap: a row below the viewport, or a tree child built after the mark was set.
• Rename one test from "as a scroll back brings one" to "as scrolling to a new one does", and correct its helper comment, so the test says which case it guards.

🧩 Type of change (check all applicable)

• 🐛 Bug fix - something not working as expected
• ✨ New feature – adds new functionality
• ♻️ Refactor - internal changes with no user impact
• ⚡ Performance Improvement
• 📝 Documentation - README or documentation site changes
• 🔧 Chore - dev tooling, CI, config
• 💥 Breaking change

📷 Screenshots / gifs / video [optional]

N/A.

🔗 Related Issues

Corrects comments added in #975.

✅ Tests added?

• 👍 yes
• 🙅 no, not needed
• 🙋 no, I need help

Comments and one test name. The nine LocatedRowMarker tests still pass unchanged.

📚 Docs updated?

• 🔖 README.md
• 🔖 CHANGELOG.md
• 📖 help site
• 🧪 Marked any pre-release-only features
• 🙅 not needed

Nothing user-visible changes.

Anything else we need to know? [optional]

No code changes: 6 insertions and 6 deletions, all inside comments and one it title.