fix: detect next/image usage in client components

[leoortizz]

Description

Thanks to @dxdc for reporting this in #10214.

When every file that imports next/image is a "use client" component, isUsingImageOptimization() fails to detect image usage because:

• Tier 1 (export-marker.json): isNextImageImported is only set for Pages Router pages — always false in App Router-only projects.
• Tier 2 (client-reference-manifest): The Image component never crosses a server→client RSC boundary, so it's never registered in the manifest.

This adds a fallback that scans prerendered HTML files under .next/server/app/ for the data-nimg=" attribute that next/image renders on every <img it produces. This attribute has been stable since Next.js 11.1, covering all supported versions (12–16). The check only runs when both existing tiers fail, so it's fully backward compatible.

Also refactors isUsingNextImageInAppDirectory into two explicit sub-checks:

• isUsingNextImageInServerComponent — scans client-reference-manifest.js (existing logic)
• isUsingNextImageInClientComponent — scans prerendered HTML for data-nimg=" (new)

Scenarios Tested

• App Router project where next/image is used in Server Components (Tier 2 detects it)
• App Router project where all next/image imports are in "use client" components (new Tier 3 detects it via data-nimg=")
• App Router project with images.unoptimized: true — correctly returns false even when data-nimg=" is present
• App Router project with no next/image usage — correctly returns false
• Pages Router project — existing Tier 1 (export-marker.json) still works

Verified against a Next.js 15.5.14 test app with "use client" on all image-importing components.

Sample Commands

firebase deploy

npx mocha --require ts-node/register src/frameworks/next/utils.spec.ts

[gemini-code-assist]

Code Review

This pull request improves the detection of next/image usage within Next.js app directories by introducing a fallback mechanism that scans prerendered HTML files for the data-nimg attribute, covering 'use client' components. The existing manifest-based check was refactored into a dedicated function for server components. Feedback suggests optimizing the combined check by executing the cheaper manifest scan first and only proceeding to the more resource-intensive HTML globbing if needed, enabling an early exit.