Import-map codegen can mis-detect Next.js client components when "use client" is read from an insufficient file prefix

[mahendra-vml]

Describe the Bug

During import-map code generation (when splitting server/client component maps for Next.js App Router), the code attempted to detect the "use client" directive by reading only a very small number of bytes from the top of each component file. This can truncate the directive (e.g., "use clien") and/or fail when the file contains BOM/CRLF/leading comments, resulting in client components being incorrectly treated as server components.

To Reproduce

1. Enable server/client split generation (Next.js App Router / separateServerClientMaps enabled).
2. Create a component file with the directive at the top, e.g.:
   'use client';
   3.. Run the import-map generation command (whatever invokes the Sitecore codegen for import maps).
3. Observe that the initial “first bytes” read can truncate the directive or fail to match it, causing the component to be classified incorrectly.
4. We noticed that it was not always the case, but sometimes it is adding the client component into the server map, which causes the issue.

Expected Behavior

• Any component whose first executable statement is 'use client' or "use client" should be reliably detected as a client component.
• The component should be included in the client import-map output (import-map.client.ts) when server/client maps are generated separately.

Possible Fix

• Read a larger file prefix (e.g., 512 bytes) and detect 'use client' as the first executable statement.
• Make detection robust to:
  - UTF‑8 BOM (\uFEFF)
  - leading whitespace/newlines
  - leading // and /* ... */ comments
  - optional trailing semicolon
• Use async file I/O and ensure file handles are always closed.
• Optionally allow the prefix length to be overridden via environment variable for edge cases.

Provide environment information

• Sitecore Version: SitecoreAI
• Content SDK Version: 1.3.2
• Nextjs App router

[art-alexeyenko]

Thank you for registering this issue @mahendra-vml and thank you for the PR fix proposal.
I've added this to our backlog so we can evaluate and proceed with the issue further.

[yavorsk]

covered in #387 and was part of the 1.5.1 release. thanks for submitting this issue @mahendra-vml :)