Improve paused prebuilds alert

Problem to solve

Following up from https://github.com/gitpod-io/gitpod/pull/14081, the new paused prebuilds alert successfully informs users about this system change and provides an action to resolve the alert.

However, there are a couple of issues that come with the current approach:

1. The paused prebuilds alert is not visible in the prebuilds page, which is the most relevant page for this message.
2. The latest prebuild information on the project card is accurate, but possibly irrelevant and not useful.
3. Clicking the action (link button) to resume prebuilds, breaks the layout of the alert message, keeps the alert on visible, is updating the link color to be the same as the rest of the alert message, etc.

See also relevant discussion (internal). Cc @AlexTugarev @jldec

Branches (project default page)	Prebuilds	Project	Resuming Prebuilds

Proposal

TBD (To be discussed)

In the meantime, here are two approaches to consider doing as minimal viable changes (MVCs):

🅰️ Move the alert to the top of the prebuilds list as an in-page alert.
- This way, we lower the risk of running into seeing multiple alerts racing for user's attention (see local preview alert[1], usage limit alert[2], etc)

🅱️ Move the alert to the top of the branches and prebuilds page.
- This is one of the most critical system status messages for a project in Gitpod, and moving this to the top of the page provides better visibility of system status.

In both cases 🅰️/🅱️, there's no need to maintain the trigger state inside the alert when resuming prebuilds. Instead, we could a) redirect to project prebuilds and b) populate the prebuilds list with the newly triggered prebuild as user feedback.

Other things to consider for next iterations include updating the project card so that the prebuilds paused state is also visible from the team page where all projects are listed. ➰

Start by reviewing PR #14081 and the paused prebuilds alert on the prebuilds page, then compare the linked screenshots with the current behavior. Resolve which proposed alert placement and resume flow should be used before implementation. Done means the alert is visible in the relevant prebuilds context, its action preserves the layout, and the resulting prebuild state is clear to the user.