[Workers] Update changelog with missing items

src/content/docs/cache/concepts/cache-control.mdx

@@ -76,7 +76,7 @@ Revalidation determines how the cache should behave when a resource expires, and
 
 * `must-revalidate` — Indicates that once the resource is stale, a cache (client or proxy) must not use the response to satisfy subsequent requests without successful validation on the origin server.
 * `proxy-revalidate` — Has the same meaning as the `must-revalidate` response directive except that it does not apply to private client caches.
-* `stale-while-revalidate=<seconds>` — When present in an HTTP response, indicates caches may serve the response in which it appears after it becomes stale, up to the indicated number of seconds since the resource expired. If [Always Online](/cache/how-to/always-online/) is enabled, then the `stale-while-revalidate` and `stale-if-error` directives are ignored. This directive is not supported when using the Cache API methods `cache.match` or `cache.put`. For more information, refer to the [Worker's documentation for Cache API](/workers/runtime-apis/cache/#methods).
+* `stale-while-revalidate=<seconds>` — When present in an HTTP response, indicates caches may serve the response in which it appears after it becomes stale, up to the indicated number of seconds since the resource expired. If [Always Online](/cache/how-to/always-online/) is enabled, then the `stale-while-revalidate` and `stale-if-error` directives are ignored. This directive is not supported when using the Cache API methods `cache.match` or `cache.put`. For more information, refer to the [Workers documentation for Cache API](/workers/runtime-apis/cache/#methods).
 
 :::note
 Currently, `stale-while-revalidate` blocks on the first request that hits a stale cache item in the cache location, when the origin returns a response it will be served to this client with a MISS or REVALIDATED status.
@@ -86,7 +86,7 @@ Any other requests that arrive while this is happening in the same cache locatio
 For more details on this, refer to example 1 of our [Revalidation and request collapsing](/cache/concepts/revalidation/#example-1) guide.
 :::
 
-* `stale-if-error=<seconds>` — Indicates that when an error is encountered, a cached stale response may be used to satisfy the request, regardless of other freshness information. To avoid this behavior, include `stale-if-error=0` directive with the object returned from the origin. This directive is not supported when using the Cache API methods `cache.match` or `cache.put`. For more information, refer to the [Worker's documentation for Cache API](/workers/runtime-apis/cache/#methods).
+* `stale-if-error=<seconds>` — Indicates that when an error is encountered, a cached stale response may be used to satisfy the request, regardless of other freshness information. To avoid this behavior, include `stale-if-error=0` directive with the object returned from the origin. This directive is not supported when using the Cache API methods `cache.match` or `cache.put`. For more information, refer to the [Workers documentation for Cache API](/workers/runtime-apis/cache/#methods).
 
 The `stale-if-error` directive is ignored if [Always Online](/cache/how-to/always-online/) is enabled or if an explicit in-protocol directive is passed. Examples of explicit in-protocol directives include a `no-store` or `no-cache cache` directive, a `must-revalidate` cache-response-directive, or an applicable `s-maxage` or `proxy-revalidate` cache-response-directive.
 

src/content/docs/workers/examples/basic-auth.mdx

@@ -22,7 +22,7 @@ import { TabItem, Tabs } from "~/components";
 
 :::note
 
-This example Worker makes use of the [Node.js Buffer API](/workers/runtime-apis/nodejs/buffer/), which is available as part of the Worker's runtime [Node.js compatibility mode](/workers/runtime-apis/nodejs/). To run this Worker, you will need to [enable the `nodejs_compat` compatibility flag](/workers/configuration/compatibility-flags/#nodejs-compatibility-flag).
+This example Worker makes use of the [Node.js Buffer API](/workers/runtime-apis/nodejs/buffer/), which is available as part of the Workers runtime [Node.js compatibility mode](/workers/runtime-apis/nodejs/). To run this Worker, you will need to [enable the `nodejs_compat` compatibility flag](/workers/configuration/compatibility-flags/#nodejs-compatibility-flag).
 :::
 
 :::caution[Caution when using in production]

src/content/docs/workers/examples/signing-requests.mdx

@@ -28,7 +28,7 @@ import { TabItem, Tabs } from "~/components";
 
 :::note
 
-This example Worker makes use of the [Node.js Buffer API](/workers/runtime-apis/nodejs/buffer/), which is available as part of the Worker's runtime [Node.js compatibility mode](/workers/runtime-apis/nodejs/). To run this Worker, you will need to [enable the `nodejs_compat` compatibility flag](/workers/runtime-apis/nodejs/#get-started).
+This example Worker makes use of the [Node.js Buffer API](/workers/runtime-apis/nodejs/buffer/), which is available as part of the Workers runtime [Node.js compatibility mode](/workers/runtime-apis/nodejs/). To run this Worker, you will need to [enable the `nodejs_compat` compatibility flag](/workers/runtime-apis/nodejs/#get-started).
 :::
 
 You can both verify and generate signed requests from within a Worker using the [Web Crypto APIs](https://developer.mozilla.org/en-US/docs/Web/API/Crypto/subtle).

src/content/release-notes/workers.yaml

@@ -3,9 +3,18 @@ link: "/workers/platform/changelog/"
 productName: Workers
 productLink: "/workers/"
 entries:
+  - publish_date: "2025-06-27"
+    description: |-
+      - Updated v8 to version 13.9.
+  - publish_date: "2025-06-23"
+    description: |-
+      - Enable FinalizationRegistry API. See [We shipped FinalizationRegistry in Workers: why you should never use it](https://blog.cloudflare.com/we-shipped-finalizationregistry-in-workers-why-you-should-never-use-it/) for details.
   - publish_date: "2025-06-04"
     description: |-
       - Updated v8 to version 13.8.
+  - publish_date: "2025-05-27"
+    description: |-
+      - Historically, in some cases, the same instance of `ctx` would be passed to multiple invocations of the event handler. We now always pass a new object for each event. We made this change retroactive to all compatibility dates because we suspect it fixes security bugs in some workers and does not break any worker. However, the old behavior can be restored using the compat flag `nonclass_entrypoint_reuses_ctx_across_invocations`.
   - publish_date: "2025-05-22"
     description: |-
       - Enabled explicit resource context management and support for Float16Array
@@ -15,6 +24,9 @@ entries:
   - publish_date: "2025-04-16"
     description: |-
       - Updated v8 to version 13.6.
+  - publish_date: "2025-04-14"
+    description: |-
+      - JSRPC message size limit has been increased to 32MiB.
   - publish_date: "2025-04-03"
     description: |-
       - Websocket client exceptions are now JS exceptions rather than internal errors.