Once we support modeling of multiple quotient-graph paths to construct individual context tokens, it's notably less straightforward to split or merge the correction-search paths on the token level. It's instead wisest to implement this via the SearchQuotientNode interface and its implementing types, which are designed to recursively model all relevant paths and thus can facilitate these operations more directly.
Build-bot: skip build:web
Test-bot: skip
A .split operation on a token requires splitting these paths appropriately. Exposing this property, for use only in unit-testing, will help to validate that split operations are performed properly.
Build-bot: skip build:web
Test-bot: skip
Now that the SearchQuotientNode rework is stabilizing, I've finally landed on a better name for the type. PendingTokenization _directly_ correlates to outbound edges from `SearchQuotientNode` entries once processed. New doc-comments are also added documenting the relationship of `TransitionEdge` and `TokenizationSubset` to `SearchQuotientSpur` and `SearchQuotientCluster`.
Admittedly, it may be wise to additionally rename `TokenizationSubset` to `TransitionCluster` (and rename the source file) to further mirror the relationship of these types... but that can always be done in a follow-up.
Build-bot: skip build:web
Test-bot: skip
This addition will allow us to clearly and cleanly indicate transforms that are two (or more) halves of the same original whole. It is notably more selective than just the original transition ID and is better suited for indicating split-transform cases.
Build-bot: skip build:web
Test-bot: skip
Once we start considering alternate tokenization schemes, we'll want to note how each potential input path aligns with the original input keystrokes. As there can be multiple paths to land within the same token, it's best to store this data on the SearchQuotientSpur objects instead. This becomes especially relevant when considering token splits and merges, which will be the next follow-ups.
Build-bot: skip build:web
Test-bot: skip
Once we enable whitespace fat-fingering, it will be possible for the 'source text' to actually _change_ after an autocorrect yet still be correctable. `.sourceText` does not reflect this adequately. What _does_ remain unchanged is the `.sourceRangeKey` property and its value - those provide a better source of stability and identification.
Build-bot: skip build:web
Test-bot: skip
