Ensure API docs don't have stale images

[Eric-Arellano]

Closes #2538. We only didn't delete the API images due to #2540.

To fix #2540, we have to fix our skip of release note images. We also had to manually move 4 release note images for legacy release note files from the latest Qiskit images folder to instead the 0.40 and 0.43 Box artifacts, then manually update those release notes to point to the paths. With those fixes and the re-uploaded Box artifacts, npm run regen-apis doesn't make changes.

This change allows us to have checkStaleImages.ts no longer worry about API docs images, which dramatically speeds up the program. It's now fast enough to run on every PR. Closes #2530.

With ripgrep:

  Time (mean ± σ):      1.705 s ±  0.022 s    [User: 1.143 s, System: 1.085 s]
  Range (min … max):    1.660 s …  1.735 s    10 runs

With git grep (CI):

  Time (mean ± σ):      4.118 s ±  0.054 s    [User: 11.290 s, System: 1.092 s]
  Range (min … max):    4.044 s …  4.200 s    10 runs

[Eric-Arellano]

Not necessary because updateApiDocs.ts will have already removed all images as part of removing Markdown.

[Eric-Arellano]

Hold off on merging. npm run regen-apis shows that these images are lost due to this PR:

docs/api/qiskit/release-notes/0.40.mdx
59:>     ![\_images/legacy\_release\_notes-2.png](/images/api/qiskit/legacy_release_notes-2.png)
349:    ![\_images/legacy\_release\_notes-3.png](/images/api/qiskit/legacy_release_notes-3.png)
599:    ![\_images/legacy\_release\_notes-4.png](/images/api/qiskit/legacy_release_notes-4.png)

docs/api/qiskit/release-notes/0.43.mdx
595:    ![\_images/legacy\_release\_notes-1.png](/images/api/qiskit/legacy_release_notes-1.png)

I need to figure out the cleanest way to fix this problem.

[arnaucasau]

Nice work!! Looking at the lost images, they were manually added to the current version folder in #346. Given that only those two versions use the legacy release note images, maybe we could store the images in their folders and manually modify their links in 0.40.mdx and 0.43.mdx to point to the new location.

[Eric-Arellano]

maybe we could store the images in their folders and manually modify their links in 0.40.mdx and 0.43.mdx to point to the new location.

Thanks for finding that. I tried that approach but we still don't copy the images because this code only copies images we actually use:

documentation/scripts/js/lib/api/conversionPipeline.ts

Lines 138 to 143 in acdcf5b

	console.log("Saving images");
	const allImages = uniqBy(
	results.flatMap((result) => result.images),
	(image) => image.fileName,
	);
	await saveImages(allImages, `${htmlPath}/_images`, publicBaseFolder, pkg);

So, I think the best approach is to instead save the images in a non-auto-generated folder.

[arnaucasau]

Nice work! Tested locally and works well! 🚀