fix(TE-4324): read testName from caps with name fallback

[sushobhit-lt]

Summary

Follow-up to merged PR #511. The previous TE-4324 series read `.name` from the LSRS `/sessions/capabilities` response, but LSRS actually returns the test name under two different keys depending on the resolution path:

LSRS path	Response key
Redis-success (`SessionInfo` JSON tag `testName`)	`testName`
LTMS-fallback (manual map `{testId, name}`)	`name`

The earlier fix only worked for the LTMS-fallback path. The primary Redis-success path silently dropped the value, so `snapshot.options.testName` was never set and `processedOptions.testName` was empty downstream. Verified against a customer log showing `fetch caps for sessionId: ... are {...,"testName":"dN6VuGgSQ6"}` while `Snapshot options:` and `Processed options:` had no testName field.

Change

Read `testName` first with `name` as fallback at all 5 caps-read sites:

• `src/lib/server.ts` — 3 caps-resolution branches (cache-hit, fresh-fetch primary, fresh-fetch LTMS-fallback)
• `src/lib/processSnapshot.ts` — 2 `sessionCapabilitiesMap` lookups in `prepareSnapshot` and `processSnapshot`

Resolution pattern: `const testName = caps.testName || caps.name;`

Test plan

• `npm run build` passes (verified)
• With a real Selenium/Playwright session against LSRS Redis-success path, confirm `Snapshot options:` debug log includes `testName`
• Confirm `Processed options:` debug log also includes `testName` (was missing before)
• Confirm DOTUI `lhps-dotlapse-add-screenshot` Kafka payload carries `testName` end-to-end
• Backward compat: LTMS-fallback path (where response key is `name`) still works

🤖 Generated with Claude Code