Remaining changes from porting suggest command

[sourishkrout]

Here is a compilation of things we may want to do before releasing the suggest branch feature.

• We should make sure auth UX for GH oauth2 is still good if things go wrong
• Tests
  • We should probably test internal/cmd/suggest.go in some capacity, though this will require some mocking (looks like we'd have to mock the gql client in some capacity)
  • We may want to integrate some CI/test to ensure that the generated schema from the API is still valid
• Integration / Refactoring
  • The suggested branch stuff is deeply tied to the model_list tui. A lot of that stuff should probably be decoupled for easier testing and to support future list TUIs
  • The TUI implemented last release does not integrate with the new internal/tui stuff - as a consequence, the UI is inconsistent with the suggestion list TUI
    • We are also violating DRY, so going forward we'll have maintenance on basically two versions of the same thing

@adambabik Your discretion would be extremely valuable here to decide exactly what of this we should commit to doing pre-release!

@sourishkrout I didn't talk about the API here, since I'm assuming its good on your end.

I'll add anything else brought up to this list going forward 👍

[adambabik]

AFAIR we definitely wanted to make sure that the API stays backward compatible, which should be enforced in the API. Checking the contract here is too late. However, provided that the API stays backward compatible, having a CI job which checks if the schema is up-to-date makes sense too.

With regards to the UI/UX, both points make sense. I would add the following ones as well:

• Explain better what the description in runme branch DESCRIPTION [flags] is.
• Make runme branch composable.