fix: fix auth flow when creating project with access token

[SerseusWasTaken]

Description

Fixes the auth flow for creating projects to be able to use STACKIT_ACCESS_TOKEN for project creation

Relates to STACKITTPR-761 and #1478

Checklist

• Issue was linked above
• Code format was applied: make fmt
• Examples were added / adjusted (see e.g. here)
• Docs are up-to-date: make generate-docs (will be checked by CI)
• Unit tests got implemented or updated
• Unit tests are passing: make test (will be checked by CI)
• No linter issues: make lint (will be checked by CI)

[github-actions]

Merging this branch changes the coverage (1 decrease, 1 increase)

Impacted Packages	Coverage Δ	🤖
github.com/stackitcloud/stackit-cli/internal/cmd/project/create	61.67% (-0.83%)	👎
github.com/stackitcloud/stackit-cli/internal/pkg/auth	56.32% (+0.36%)	👍

---

Coverage by file

Changed files (no unit tests)

Changed File	Coverage Δ	Total	Covered	Missed	🤖
github.com/stackitcloud/stackit-cli/internal/cmd/project/create/create.go	61.67% (-0.83%)	60 (-12)	37 (-8)	23 (-4)	👎
github.com/stackitcloud/stackit-cli/internal/pkg/auth/auth.go	48.36% (+1.69%)	122 (+2)	59 (+3)	63 (-1)	👍
github.com/stackitcloud/stackit-cli/internal/pkg/auth/storage.go	77.17% (+0.25%)	184 (+2)	142 (+2)	42	👍

Please note that the "Total", "Covered", and "Missed" counts above refer to code statements instead of lines of code. The value in brackets refers to the test coverage of that file in the old version of the code.

Changed unit test files

• github.com/stackitcloud/stackit-cli/internal/cmd/project/create/create_test.go
• github.com/stackitcloud/stackit-cli/internal/pkg/auth/auth_test.go
• github.com/stackitcloud/stackit-cli/internal/pkg/auth/storage_test.go

[cgoetz-inovex]

I'm not quite sure about this one. Decisions on which AuthFlow to use seem to be done in functions where SetAuthFlow() is called.

What's the reason to include this change?

[SerseusWasTaken]

My intention was to guarantee that the access token is used when it is set. Before, it as possible to have the token set and still be treated unauthenticated by the CLI which why the original issue came up. I personally don't see a reason not to use the token when it is set.

With this change, GetAuthFlow is now aware of the token's existence. Does that make sense?