fix(stega): 2x faster encoding of portable text

[stipsan]

We got a report of a really slow request that only happens if stega is enabled, here's how to repro:

const {createClient, stegaEncodeSourceMap} = await import('https://esm.sh/@sanity/client/stega')

const client = createClient({
  projectId: '4n2hubkf',
  dataset: 'production',
  apiVersion: '2024-11-15',
  useCdn: true,
  stega: {studioUrl: '/studio'}
})

const {result, resultSourceMap} = await client.fetch(`{
    "entries": *[_type == "post"] | order(publishedAt desc) {
    ...,
    title,
    excerpt,
    date,
    author-> {
        ...,
    },
},
}`, {}, {resultSourceMap: 'withKeyArraySelector', filterResponse: false})

console.profile()
stegaEncodeSourceMap(result, resultSourceMap, {enabled: true, studioUrl: '/studio'})
console.profileEnd()

Turns out the root cause was a lot of portable text arrays that were deeply recursed.

This PR adds short circuit logic for when a PT block or span is detected, and traverses them more efficiently.
To measure the impact I've added a npm run benchmark command:

 ✓ test/stega/stegaEncodeSourceMap.bench.ts (2) 5795ms
   ✓ stegaEncodeSourceMap can handle Portable Text in a performant way (2) 5793ms
     name                       hz     min     max    mean     p75     p99    p995    p999     rme  samples
   · @sanity/client@latest  4.3355  221.82  282.11  230.65  228.15  282.11  282.11  282.11  ±5.67%       10
   · src                    9.3105  105.54  109.67  107.41  107.81  109.67  109.67  109.67  ±0.84%       10   fastest

It uses the benchmarking feature in Vitest, so we can add more benchmarks in the future 🙌

As a side-effect of the more efficient recursion there's no longer a need to handle PT edge cases in the stega filterDefault function 😌