Ask github if the preview deploy action has succeeded for this commit, rather than probing the preview URL

[eyeseast]

Closes #1411

This removes the old wait job and does everything with the Github API (using gh).

[github-actions]

Preview removed.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	50.58%	3884 / 7678
🔵	Statements	49%	4523 / 9230
🔵	Functions	43.84%	1446 / 3298
🔵	Branches	47.78%	1970 / 4123

File Coverage

No changed files found.

Generated in workflow #1374 for commit 172058f by the Vitest Coverage Report Action

[duckduckgrayduck]

Asking for readability and because I'm curious, is there a reason we can't move the wait_for_response that we currently use into the test job just behind connecting to the VPN? Both wait_for_response and the rest of the test will then have access to the VPN and work. We also trim down on one job and don't have to pass in the github token

[eyeseast]

We could definitely do that. One thing I've never liked about the current approach -- making a request and checking for a 200 -- is that it's not tied to the commit. So if I open a PR and then push another commit, the test could run before the new version builds, because it'll hit a 200 right away. This guarantees it waits for the build to finish and triggers on that.

[duckduckgrayduck]

That makes sense. I'm good with either approach, just was curious why you decided this way over the other