blog: fix typos and broken URL in async_hooks post

- Fix "Why The Is" -> "Why This Is" in section heading
- Add missing period between "V8" and "JavaScript"
- Fix broken nodejs.org URL (misplaced quote)
- Remove duplicate timeline entry

Co-Authored-By: Joyee Cheung <joyeec9h3@gmail.com>

Author: mcollina

apps/site/pages/en/blog/vulnerability/january-2026-dos-mitigation-async-hooks.md

@@ -292,7 +292,7 @@ The complete sequence when stack overflow occurs:
 
 The error originated in **user code** (the recursive pattern), but because it manifests while the hook callback is the active frame, it's treated as a fatal hook error.
 
-## Why The Is Only a Mitigation, and The Vulnerability Lies Elsewhere
+## Why This Is Only a Mitigation, and The Vulnerability Lies Elsewhere
 
 While this issue has significant practical impact, we want to be clear about why Node.js is treating this fix as a mere mitigation of security vulnerability risks at large:
 
@@ -304,11 +304,11 @@ It's worth noting that even when ECMAScript specifies that [proper tail calls](h
 
 ### V8 Doesn't Treat This as a Security Issue
 
-Node.js's stack overflow handling is primarily implemented by V8JavaScript engines developed for browsers have a different security model, and they do not treat crashes like this as security vulnerabilities ([example](https://issues.chromium.org/issues/432385241)). This means similar bugs reported in the upstream will not go through vulnerability disclosure procedures, making any security classification by Node.js alone ineffective.
+Node.js's stack overflow handling is primarily implemented by V8. JavaScript engines developed for browsers have a different security model, and they do not treat crashes like this as security vulnerabilities ([example](https://issues.chromium.org/issues/432385241)). This means similar bugs reported in the upstream will not go through vulnerability disclosure procedures, making any security classification by Node.js alone ineffective.
 
 ### uncaughtException Limitations
 
-The `uncaughtException` handler is not designed to recover the process after it fires. The Node.js documentation explicitly warns against this pattern. Specifically, the documentation states that ["Exceptions thrown from within the event handler will not be caught. Instead, the process will exit with a non-zero exit code, and the stack trace will be printed. This is to avoid infinite recursion."](https://nodejs."org/api/process.html#warning-using-uncaughtexception-correctly)
+The `uncaughtException` handler is not designed to recover the process after it fires. The Node.js documentation explicitly warns against this pattern. Specifically, the documentation states that ["Exceptions thrown from within the event handler will not be caught. Instead, the process will exit with a non-zero exit code, and the stack trace will be printed. This is to avoid infinite recursion."](https://nodejs.org/api/process.html#warning-using-uncaughtexception-correctly)
 
 Trying to invoke the handler after the call stack size is exceeded would itself throw. The fact that it works without promise hooks is largely coincidental rather than guaranteed behavior.
 
@@ -402,7 +402,6 @@ If you cannot upgrade immediately, consider altering your application to avoid d
 
 - **December 7, 2025**: React/Next.js team contacted Matteo Collina to report this issue
 - **December 8, 2025**: Vercel Security team opens the [HackerOne report #3456295](https://hackerone.com/reports/3456295)
-- **December 9, 2025**: Vercel Security team opens the [HackerOne report #3456295](https://hackerone.com/reports/3456295)
 - **December 9, 2025**: Matteo Collina starts working on a first patch that would defer the stack overflow error to the next macrotick.
 - **December 10, 2025**: The React/Next.js team validates that this patch did not fix the problem.
 - **December 10, 2025**: Matteo Collina prepares a different patch that rethrow the error immediately, freeing the stack.