docs(guide): clarify manifest.json structure and valid chunk types in backend integration

[dileepapeiris]

Description

Fixes #20858

Improves the Backend Integration Guide by clarifying the manifest.json structure and addressing confusion about which chunk types can have specific fields.

---

Key Improvements

• Clarified chunk type distinctions:
  Added explicit documentation explaining that only JS chunks can have imports, dynamicImports, css, and assets fields, while CSS files and asset chunks only have file, src, and optionally isEntry / name fields.

• Enhanced processing instructions:
  Updated step-by-step instructions to emphasize that CSS files and assets in the manifest do not have imports, preventing incorrect recursive processing.

• Improved pseudo-implementation documentation:
  Added notes to the importedChunks function example clarifying that it only processes JS chunks and that CSS dependencies are accessed via the css field.

• Added “Common Questions” section:
  New FAQ section addresses:

  • Whether CSS files can have imports in the manifest (they cannot)
  • How CSS dependencies are correctly represented (in JS chunk’s css array)
  • Guidelines for implementing manifest parsers

---

Additional Context

The documentation now makes it clear that the hypothetical scenario in #20858 (CSS chunks with imports and nested css fields) is invalid because CSS files are OutputAsset types that don’t support these fields.
This should prevent confusion for developers implementing custom backend integrations.

The changes are documentation-only with no code modifications.
The manifest generation code in manifest.ts already correctly enforces these constraints; the documentation simply lacked explicit clarification about these edge cases.