bin/generate-readme.mjs: 404 support-doc fallback is skipped and Link header parse can throw

[akgitrepos]

Summary

bin/generate-readme.mjs has two edge-case bugs on main:

1. Support docs fallback is skipped when HEAD returns HTTP 404.
2. README generation can throw when parse-link-header returns null.

Both are reproducible on current upstream/main and affect README generation reliability.

Environment

• Repo: googleapis/google-cloud-node
• Script: bin/generate-readme.mjs
• Verified on: main at a0e6fcbf05292d3fa60c8090295365b1180656bc

Repro 1: 404 fallback mismatch

Why this happens

The script uses validateStatus: () => true, so a 404 response does not throw.
Fallback to product_documentation is currently handled primarily in catch, so this path can be skipped.

Steps

1. On main, inspect processMetadata in bin/generate-readme.mjs.
2. Note validateStatus: () => true on the HEAD request and fallback logic in catch.
3. Simulate HEAD returning { status: 404 } (no throw).

Actual

remoteUrlExists can stay true, so support_documentation may incorrectly remain .../docs/getting-support even when that page is 404.

Expected

When HEAD returns 404, fallback should use product_documentation.

Repro 2: null Link header parse dereference

Why this happens

parse-link-header can return null for malformed/oversized headers.
Current code dereferences link.next without a null guard.

Steps

1. On main, inspect getRepos in bin/generate-readme.mjs.
2. Simulate parseLinkHeader(res.headers.link) returning null.
3. Run the logic that checks if (link.next).

Actual

Throws TypeError: Cannot read properties of null (reading 'next').

Expected

If parsing returns null, generation should continue without throwing.

Impact

• Can produce incorrect support links in generated README metadata.
• Can terminate README generation unexpectedly on malformed/oversized Link headers.

Proposed fix

A fix has already been implemented here:
#7305

[akgitrepos]

@danieljbruce I have raised the issue for triage corresponding to the fix PR 7305 like you said.

[danieljbruce]

A few thoughts here:

1. This actually looks like two separate issues based on the fact that there are two tests and each test pertains to a different function. If we end up making actual changes here then would you mind replacing this issue with two separate issues?
2. This issue pertains to two helper methods. Is there a code sample you can provide that shows the problem from the perspective of the user? In the steps part of your repro we need something like a code sample that imports a library and then a comment in the sample about the output we don't want.