When a cache tag contains a non-ASCII character (Hebrew, CJK, emoji, …)
it gets written into the internal `x-next-cache-tags` HTTP header on ISR
responses. Node's `validateHeaderValue` rejects any byte outside
`\t\x20-\x7e`, so the response crashes with `ERR_INVALID_CHAR`. On
Vercel deploys stale-if-error masks the 500 from clients, but
revalidation itself keeps failing and the cache stops refreshing for
affected routes.

This change introduces a single `encodeCacheTag` helper and applies it
at every public boundary — `validateTags` (which `cacheTag()`,
`unstable_cache()`, and `fetch` tags all funnel through),
`getImplicitTags` for path-derived tags, and `revalidatePath` /
`revalidateTag` / `updateTag` for invalidation inputs. The encoder
matches runs of out-of-class code units so surrogate pairs reach
`encodeURIComponent` intact, and it is idempotent on already-encoded
`%xx` sequences, so callers can pass either the raw or the encoded form
interchangeably.

PR #93139 already encodes path-derived tags at construction, but it
misses every user-supplied tag entry point and uses a
`decodeURIComponent` round-trip that silently mangles literal `%xx`
characters in tag values. PR #93167 encodes only at the `setHeader`
sites, which leaves storage and invalidation diverging and requires
every new write site to remember the encoding step. The
canonical-form-at-the-boundary approach taken here covers all entry
points and keeps storage, comparison, and the wire in sync.

fixes #93142
closes #93139
closes #93167

Co-authored-by: Swarnava Sengupta <swarnava.sengupta@vercel.com>
Co-authored-by: Or Nakash <ornakash@gmail.com>