Add release channel support for remote server downloads

[juliasilge]

Addresses #11382

When Positron connects to WSL, SSH, or dev container remote hosts, it downloads a server build from the CDN. Right now, we always download from the dailies/ CDN path, which only retains builds for 60 days. After 60 days, users on a particular monthly release can no longer connect to remote hosts.

This PR adds a quality field to product.json that we can then use to control the CDN path for remote server downloads:

• dailies (default): For daily builds from main branch
• releases: For monthly releases from release/* branches

The value is set at build time via the VSCODE_QUALITY environment variable (at least right now; see my comment below about how we can make this whatever we want). A follow-up PR in positron-builds will set this environment variable based on the source branch.

What happens after this PR is merged but before we make changes to our builds?

• All builds (daily AND release) will have quality: "dailies" since our env var is not yet set in the build workflows
• Remote server downloads will continue using the dailies/ CDN path
• This is identical to current behavior; nothing breaks, but the 60-day issue is not yet fixed

What happens positron-builds changes?

• Daily builds: quality: "dailies" → downloads from dailies/ (60-day retention)
• Release builds: quality: "releases" → downloads from releases/ (permanent retention)
• The 60-day issue will be fixed for monthly release users

Release Notes

New Features

• N/A

Bug Fixes

• Fix remote host connections failing after 60 days for monthly release users (Use of dailies in WSL server build download does not work >60 days beyond that release #11382)

QA Notes

@:remote-ssh

To verify the implementation locally:

1. Build Positron without setting the env var:

   cat <build-path>/resources/app/product.json | grep '"quality"'
   # Expected: "quality": "dailies"

2. Build with the env var set:

   VSCODE_QUALITY=potato <your-build-command>
   cat <build-path>/resources/app/product.json | grep '"quality"'
   # Expected: "quality": "potato"

Obviously, this will not be what we use, but it shows you how we are setting this up. 🥔

3. Verify the URL template includes ${quality}:

   cat <build-path>/resources/app/product.json | grep 'serverDownloadUrlTemplate'
   # Expected: "https://cdn.posit.co/positron/${quality}/reh/..."

[github-actions]

E2E Tests 🚀
This PR will run tests tagged with: @:critical @:remote-ssh

^{readme  valid tags}

[juliasilge]

In the gulp files, we import releaseChannel and then put it into the product.json in the field quality. We want to use quality because it is what we can use for URL templating.

[juliasilge]

We can use whatever env var we want here. For example, this could be:

Suggested change

	export const releaseChannel = process.env.VSCODE_QUALITY ?? 'dailies';
	export const releaseChannel = process.env.RELEASE_CHANNEL ?? 'dailies';

What env var do we want to set over in positron-builds?

[juliasilge]

This quality placeholder is already plumbed through in all the right places for us to use in this way.

[juliasilge]

This is not an upstream file, so I think it's fine for us to change this, right?