UXP: Source Text param on AE.ADBE Text returns no value (other 21 params on the same component work)

Premiere Pro 26.0.1 (build 3) / macOS 15 / UXP "premierepro" API

SUMMARY
On a native text clip, the AE.ADBE Text component exposes a param named
"Source Text" (index 0). The param object and its displayName come back fine,
but its value cannot be read. All 21 other params on the same component
return values normally.

STEPS TO REPRODUCE
1. Create a text clip with the Type tool in a sequence.
2. Select the clip in the timeline.
3. From a UXP plugin:
   const chain = await trackItem.getComponentChain();
   const text  = chain.getComponentAtIndex(3);   // matchName "AE.ADBE Text"
   const param = text.getParam(0);               // displayName "Source Text"
   await param.getValueAtTime(ppro.TickTime.createWithSeconds(0));
   await param.getStartValue();

EXPECTED
The Source Text value is returned.

ACTUAL
Neither call returns a value. areKeyframesSupported() is false.
Position, Scale, Rotation, Opacity, Anchor Point etc. on the same component
all return values correctly (e.g. Position -> [0.1324, 0.7087]).

THE VALUE DOES EXIST
1) ExtendScript returns a truncated form of it. getValue() does not throw;
   it returns a 1-character string, U+0164. 0x0164 is exactly the first two
   bytes of the underlying buffer (64 01, little-endian), after which a NUL
   pair terminates the string. The value is a binary buffer being marshalled
   as a UTF-16 string. (Noted for diagnosis only - not asking for an
   ExtendScript fix, given its announced end of support.)

2) In the .prproj the same value is stored under AE.ADBE Text as
   <StartKeyframeValue Encoding="base64">. Decoded, it is a FlatBuffers-like
   buffer (magic 0x11223344) holding the font name, font size as float32,
   and the text as UTF-8.

3) It already models per-character style runs. Setting one word to a
   different size in the Properties panel and re-saving changed the style-run
   count from 1 to 3 (buffer 368 -> 500 bytes). The three runs decoded to
   size 103.0 "字面", size 60.0 "ヨシ", size 103.0 "！やってみたバージョン1" -
   split exactly at the boundary that was changed.

So Premiere's text model already supports per-run styling. Plugins just have
no way to reach it.

POSSIBLY RELATED
There is another open report, "[UXP] Color parameter writes lose the blue
channel", where writing a Color value to an effect parameter drops a channel.
Both look like ComponentParam value-marshalling defects rather than missing
features: the parameter is reachable, but its value does not survive the
crossing. It may be worth looking at them together.

WHAT WOULD UNBLOCK US (any one is enough)
1. Minimum: let ComponentParam return and accept the Source Text value as a
   raw buffer (ArrayBuffer / Uint8Array) so a plugin can round-trip it. Even
   undocumented, this makes read-modify-write possible.
2. Preferred: a documented API exposing style runs with fontName, fontSize,
   tracking and baselineShift per character range - as After Effects has.
3. Otherwise: a public note on the intended direction and rough timeline.

WHY IT MATTERS
Japanese typesetting needs per-character adjustment: hiragana set slightly
smaller than kanji, ASCII digits scaled up to match surrounding visual height,
punctuation side bearings tightened. Editors do this by hand on every
subtitle. Such tools exist for After Effects and cannot exist for Premiere Pro
today, even though Premiere's own data model already represents what they
would need to write.

I can share the decoded sample buffers or a minimal reproduction plugin.