Possibly remove ShortcutTransition

If you look at Quamina's equivalent of `ByteMachine` you see the following fields:

```go
startDfa *smallTable[*dfaStep]
singletonMatch []byte
singletonTransition *fieldMatcher
```

The idea is that if there is only one possible value for a field, you don't even make a machine, you just put the value in `singletonMatch` and add transition target for it. In my measurements, this turns out to be a common occurrence. The traversal logic is easy:

```go
case fields.singletonMatch != nil:
// if there's a singleton entry here, we either match the val or we're
// done. Note: We have to check this first because addTransition might be
// busy constructing an automaton, but it's not ready for use yet. When
// it's done it'll zero out the singletonMatch
if bytes.Equal(fields.singletonMatch, val) {
transitions = append(transitions, fields.singletonTransition)
}
return transitions
```

The reason why this might be a good idea is that when I was measuring things, `ShortcutTransition` was almost always at the first state of the machine. The conclusion is that a field with just one possible value is common, but with multiple values that have a **common suffix** is kind of rare. Possibly wildcards will change that? Anyhow, the `SingletonTransition` really adds a lot of work to `AddRule` and `DeleteRule` and I suspect isn't offering any more benefit than Quamina's approach.

Start by locating ShortcutTransition and the AddRule and DeleteRule entry points, then compare their behavior with Quamina's singletonMatch and singletonTransition approach shown in the issue. Measure whether removing ShortcutTransition preserves matching behavior and improves rule updates, including cases involving wildcards; done means the implementation and measurements support a clear keep-or-remove decision.

Written by the indexing model from the issue text.