fix: honor --auth option

[pieh]

🎉 Thanks for submitting a pull request! 🎉

Summary

Fixes https://linear.app/netlify/issue/FRB-1343/internal-server-error-on-netlify-builds-via-bitbucket-pipeline-missing

Our --auth CLI option handling seems a bit hit and miss. We had a lot of optional argument and @ts-expect-error around code that was dealing with tokens - this removes all of those, adjust types to require token from CLI toggle being passed in to helper functions (do note that this doesn't fully ensure type safety, because options.auth has type any, but at least it ensures that something is passed in instead of being optional)

---

For us to review and ship your PR efficiently, please perform the following steps:

• Open a bug/issue before writing your code 🧑‍💻. This ensures we can discuss the changes and get feedback from everyone that should be involved. If you`re fixing a typo or something that`s on fire 🔥 (e.g. incident related), you can skip this step.
• Read the contribution guidelines 📖. This ensures your code follows our style guide and
  passes our tests.
• Update or add tests (if any source code was changed or added) 🧪
• Update or add documentation (if features were changed or added) 📝
• Make sure the status checks below are successful ✅

A picture of a cute animal (not mandatory, but encouraged)

[pieh]

token here is of type string | null, while runCoreSteps expect it to be string | undefined

Overall at this stage there should be a token always, otherwise we would bail much earlier, but stuff like this is annoying with TS and probably would need more refactoring to not have to deal with null / undefined cases.

[pieh]

Note that this one will have a potential change in behavior - by using command.authenticate (like almost all the other commands, except for status, login, logout and build) - this will start auth flow if user is not logged in (or didn't provide token via env var or --auth), while previously it would result in getting no token (and presumably getting failures later down the road?)

After fixing up bunch of related TypeScript elsewhere, using the getToken that could be null (previously it would be just any) it would complain about token being possibly null in

cli/src/commands/integration/deploy.ts

Lines 421 to 428 in e64e30c

	const { body: registeredIntegration, statusCode } = await fetch(
	`${getIntegrationAPIUrl()}/${accountId}/integrations?site_id=${siteId}`,
	{
	headers: {
	'netlify-token': token,
	},
	},
	).then(async (res) => {

so I assume this should be required that token is present before executing the rest of this command?

cc @netlify/ecosystem-pod-composable-tooling

[pieh]

this test alone was failing (at least in GHA) without code changes done in 2nd commit

[serhalp]

@pieh is this something we want to get over the finish line?