feat(log-viewer): read the user and entry point from the parser

[lukecotter]

📝 PR Overview

Stacked on #1068 — base is feat-adopt-apex-log-parser, not main.

logIdentity.ts carried TODO(spike): hoist USER_INFO onto ApexLog in the parser and drop the raw-text scan. 0.1.1 does exactly that, so the scan and the local code-unit walk both go. The
parser was already paying for its own USER_INFO scan on every log, so this deletes duplicated
work rather than moving it.

🛠️ Changes made

• parseUserInfo(rawLog) and TIMESTAMPED_LINE → log.userInfo. deriveLogIdentity takes the
  log alone; the rawLog parameter and the two now-false comment lines at the call site go.
• firstCodeUnit(log) → log.entryPoint. The parser's findEntryPoint is the same traversal
  statement for statement — same root-children order, same one-level descent into
  ExecutionStartedLine, same null — so the header names the same code unit.
• entryPointLabel stays local. It is display copy (Anonymous Apex, VF <page>,
  Trigger <name>), not parsing.
• The timezone is rebuilt from the parts the parser splits it into, to keep the tooltip's wording.
• Fix: the user is keyed on the name, not on the header line. The old scan returned null for a
  USER_INFO with no username; the parser returns {userName: ''}, which is truthy, so the header
  would have drawn a • separator around an empty item with an empty tooltip. Covered by a new test.

🧩 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]

None — the header renders as before. The start-time tooltip still reads
Started 10:29:24.600 (GMT-07:00) Pacific Daylight Time (America/Los_Angeles) on
sample-app/debug-logs/sample-log.log, verified byte-for-byte against the old code.

🔗 Related Issues

related apex-dev-tools/apex-log-parser#85
related apex-dev-tools/apex-log-parser#86

✅ Tests added?

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

Two added — the empty-username case above, and a header stating an offset but no zone name. One
deleted: finds USER_INFO past a preamble longer than any fixed scan window asserted parser
behaviour rather than ours. One renamed to what it actually asserts, since the parser searches
everything before EXECUTION_STARTED rather than bailing at the first timestamped line.

2085 tests across 156 suites pass.

📚 Docs updated?

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

## [Unreleased] already carries "🪪 Header: shows the entry point, user and start time". This
is the mechanism behind a shipped feature.

Anything else we need to know? [optional]

Verified: pnpm lint 0 errors · 2085 tests in 156 suites · prettier --check and typecheck
clean on the changed paths.

The timezone is re-synthesised, and that is not perfectly faithful. The parser splits the
USER_INFO timezone field into {label, name, offsetMinutes} and keeps no copy of the original, so
the wording has to be rebuilt. The offset reproduces exactly, half-hour zones included, but four
distinct field spellings collapse into two parse results — nothing says whether the log carried a
(GMT…) prefix. Measured divergences:

log states	we render
(GMT-07:00) Pacific Daylight Time (America/Los_Angeles)	identical
Greenwich Mean Time	(GMT+01:00) Greenwich Mean Time — prefix added
(GMTZ) Coordinated Universal Time (UTC)	(GMT+00:00) … — respelled

Each states something true; none states something false. The dominant shape — the only one in this
repo's real logs — is byte-identical. apex-log-parser#85 asks for the source text, which would
delete the rebuild entirely.

A parser bug ships with this, raised as apex-log-parser#86. parseUserInfo bounds its search
with log.indexOf('|EXECUTION_STARTED'), which can match inside the Execute Anonymous: source
echo. Apex containing that literal loses the user chip and the tooltip's timezone. The same wrong
window means a log with no EXECUTION_STARTED can take a USER_INFO line out of a USER_DEBUG
payload, and makes the scan cost 36 ms on a 50 MB log where it should cost microseconds. None is
fixable here without restoring the scan this PR removes.