[Workers] deeplink to images bindings

Images bindings are hard to find from the main "images" landing page.
Linking directly to them saves some confusion.

Author: taylorlee

src/content/docs/workers/reference/migrate-to-module-workers.mdx

@@ -16,7 +16,7 @@ There are several reasons to migrate your Workers to the ES modules format:
 
 1. Your Worker will run faster. With service workers, bindings are exposed as globals. This means that for every request, the Workers runtime must create a new JavaScript execution context, which adds overhead and time. Workers written using ES modules can reuse the same execution context across multiple requests.
 2. Implementing [Durable Objects](/durable-objects/) requires Workers that use ES modules.
-3. Bindings for [D1](/d1/), [Workers AI](/workers-ai/), [Vectorize](/vectorize/), [Workflows](/workflows/), and [Images](/images/) can only be used from Workers that use ES modules.
+3. Bindings for [D1](/d1/), [Workers AI](/workers-ai/), [Vectorize](/vectorize/), [Workflows](/workflows/), and [Images](/images/transform-images/bindings/) can only be used from Workers that use ES modules.
 4. You can [gradually deploy changes to your Worker](/workers/configuration/versions-and-deployments/gradual-deployments/) when you use the ES modules format.
 5. You can easily publish Workers using ES modules to `npm`, allowing you to import and reuse Workers within your codebase.
 

src/content/docs/workers/runtime-apis/bindings/images.mdx

@@ -1,7 +1,7 @@
 ---
 pcx_content_type: navigation
 title: Images
-external_link: /images
+external_link: /images/transform-images/bindings/
 head: []
 description: Store, transform, optimize, and deliver images at scale.