fix(DORIS-2053): apply WebVTT cue settings when dispatchForManualRendering is enabled

[eowino]

Problem

TextTracks.addCaptions picks the cue-construction path based on the dispatchForManualRendering setting:

if (dispatchForManualRendering) {
    cue = _handleCaptionEvents(currentItem, timeOffset);        // did NOT apply styles
} else if (_isHTMLCue(currentItem) && captionContainer) {
    cue = _handleHtmlCaption(currentItem, timeOffset, track);
} else if (currentItem.data) {
    cue = _handleNonHtmlCaption(currentItem, timeOffset, track); // applied styles
}

Only _handleNonHtmlCaption copied currentItem.styles onto the cue. With dispatchForManualRendering: true, _handleCaptionEvents returned the cue unstyled, so align / line / position / size parsed out of the WebVTT were silently dropped and every cue rendered bottom-centre regardless of its cue settings.

VTTParser was never at fault — it returns the settings correctly. They were discarded downstream.

Fix

Move the style application out of _handleNonHtmlCaption into _getCueInformationForNonHtml, the constructor every non-HTML path funnels through via _getCueInformation.

Fixing the shared constructor rather than the one broken caller also covers _appendFragmentedWebVtt (wvtt in fMP4), which had the identical defect. The HTML/TTML path (_getCueInformationForHtml) is untouched.

Behavioural note: settings are now applied during cue construction rather than after _getCueInformation returns. _handleCaptionEvents only deletes cue.type in onenter, and manualCueProcessing reads track.manualCueList — neither touches positioning.