feat: add istanbul-lib-coverage to preferred replacements

[ChrisJr404]

Adds istanbul-lib-coverage to the preferred manifest, pointing at the maintained @vitest/istanbul-lib-coverage fork, since the original is no longer maintained.

The fork keeps the same API so migrating is mostly just swapping the import, and it ships as ESM with its own types. I added a docs page covering that.

Closes #993

[gameroman]

Should we also add other istanbul-* packages in the same PR?

[dreyfus92]

thanks @ChrisJr404 for putting this together, and @AriPerkkio for the quick review.

one thing I was wondering about while reading the docs page: the fork has engines: node >=22 and ships ESM-only, which is a bigger jump than "just swap the import" for some projects. would it be worth a line or two mentioning that, so people on older Node or CJS aren't caught off guard?

@gameroman good call on the other istanbul-* packages, but i'd rather keep this PR scoped to istanbul-lib-coverage since the linked issue covers just this one and it's already approved. would you mind opening a tracking issue for the rest?

[43081j]

this should probably be worded similar to the others, "Modern alternatives to ..."

[43081j]

the context around the vitest fork should be in the vitest section, leaving only the "no longer maintained" message here i think

[ChrisJr404]

Updated the doc per the review:

• Frontmatter now uses the "Modern alternatives to ..." wording like the other pages.
• The intro is just the "no longer maintained" line; the fork context now lives under the @vitest/istanbul-lib-coverage section.
• Added a note that the fork is ESM-only and sets engines.node to >=22, so it is a bigger jump than a plain import swap for CommonJS or older-Node projects (thanks @dreyfus92).

@gameroman I'd like to keep this PR scoped to istanbul-lib-coverage since that is what the linked issue covers; happy to see the other istanbul-* packages tracked separately.

Heads up on the validate check: it fails because @vitest/istanbul-lib-coverage is at ~1.9k weekly downloads, under the 10k threshold in scripts/validate-pr.ts. That is a policy call on a maintained-but-low-traffic fork rather than something I can change, so I will leave that decision to you all.