### Why?
Should come up with better solution that does not block PRs with git
conflict
x-ref:
https://vercel.slack.com/archives/C02CDC2ALJH/p1785263902728189?thread_ts=1785263687.502649&cid=C02CDC2ALJH
### How?
- Delete `errors.json`, the error-code SWC plugin, generated WASM, merge
driver, and validation/build tooling.
- Stop attaching error codes to server-rendering digests, redboxes, and
telemetry; native `Error.code` and `Error.name` remain available where
applicable.
- Remove the development-overlay error feedback UI, middleware, and
telemetry event that depended on stable codes.
- Update fixtures, snapshots, and guidance for code-free errors and
numeric-only digests.
<!-- NEXT_JS_LLM -->
In practical terms, clicking the name of a route segment in the Suspense
DevTools should select the child slots of that layout, because when you
focus on it, what you're interested in debugging are navigations that
occur within the shared layout.
So the name we apply to the Activity boundary is actually based on the
name of the *parent* segment.
If a layout or page is marked with "use client", we do not need to pass
any runtime params from the server; the client can parse them from the
URL, or (in the case of a rewrite) from the x-next-rewritten-path and
x-next-rewritten-query headers. This means the client can treat the
segment as fully static, and no dynamic request is necessary upon
navigation.
When `routerBfCache` is enabled, React's Activity API renders inactive
route segments offscreen to enable instant back/forward navigation.
However, the layout-router's lazy data fetching logic was incorrectly
triggering fetchServerResponse calls for these offscreen segments when
data was missing.
This PR adds an isActive prop to InnerLayoutRouter that tracks whether a
segment is currently visible via the existing `stateKey` check.
The current animation strategy for our Dev Tools surface does not work.
https://github.com/user-attachments/assets/a0ca5459-9d5a-4d90-af00-b071d43581e0
On page load, several animations can be observed:
- Width growth from `0` → `auto`
- Issue count translates and fades, along with the plural `s` suffix
- A subtle scale bounce effect plays
All these animations are state transitions, and thus we should ignore
them completely on page load or on high-frequency updates where
animating is undesirable, e.g. sometimes `issueCount` will receive
updates faster than the animation can run.
This PR implements checks to guard the animations from being executed on
page load, _and only_ during state transitions.
To review, it is worth checking out the
[/animation-test](https://github.com/vercel/next.js/blob/a6e6fe635b712020d4ea2d027040d838eb5941c6/test/development/app-dir/hydration-error-count/app/animation-test/page.tsx)
fixture I've set up in this PR.
After these changes, the experience is as follows—no animations on page
load, but only on subsequent low-frequency updates (count change, or
collapse of the surface):
https://github.com/user-attachments/assets/7b2d5e0d-64ec-4165-b5e2-85489bd00a2c
_Note: I am not using Storybook for a page load reference, the apps
under `test/development/app-dir/*` are more reliable._
### What
Addressing the hack we introduced in #71483, where we always display the
hydration error with squashed hydration info into the first error. Now
we're displaying the errors with its own corresponding hydration info
properly, so we don't have to order it in a certain place, but just test
the displayed error itself.
Closes NDX-484
### What
We should treat each line's first character to determine the leading
sign, rather than treating the trimed line's first character as sign.
The bad case was the close tag `>` was treated as leading error sign
```
> <p // should be treated as errored line ✅
> // should not be treated as errored line ❌
```
Also align the attribute name for highlighted lines
Jiwon Choi