CLI fails completely (start/update) when GITHUB_TOKEN is set with insufficient permissions — should fall back gracefully

Summary

When GITHUB_TOKEN is set in the environment, the Amplifier CLI fails completely — it cannot start, cannot self-update, etc. This appears to happen when the token does not have the required permissions (e.g. a token exported globally for another tool that happens to lack the scope the CLI needs, or one scoped to a different org).

Impact

A single unrelated GITHUB_TOKEN in the environment can render the CLI entirely unusable. Many developers keep a GITHUB_TOKEN exported globally for other tooling, so this is easy to hit and produces a hard failure with no obvious cause.

Expected behavior

The CLI should degrade gracefully instead of failing hard when GITHUB_TOKEN is present but insufficient. At least one of:

1. Fall back to a different auth mechanism (e.g. gh CLI credentials, SSH, or anonymous/unauthenticated access) when the provided token is rejected (401/403).
2. Fall back to whatever is already cached locally, so the CLI can still start and run with previously fetched resources even if the token-based fetch fails.
3. At minimum, treat an invalid/insufficient token as "no usable token" and continue with a clear warning instead of a fatal error.

Actual behavior

With GITHUB_TOKEN set to a token lacking the right permissions, the CLI fails completely — startup and self-update both fail.

Suggested fix

• Detect auth failures on token-based GitHub requests and fall back to alternate auth or unauthenticated/cached paths rather than aborting.
• Never treat a GitHub fetch failure as fatal when a viable local cache exists.

Environment

• Package: amplifier-app-cli 0.1.1 (amplifier-core 1.6.1)
• Platform: Linux (Linux-6.17.0-8-generic-x86_64, glibc 2.42)
• Trigger: GITHUB_TOKEN set with insufficient permissions

(Filed against microsoft/amplifier because Issues are disabled on microsoft/amplifier-app-cli, which is the package that exhibits the bug.)

Reproduce the failure with an insufficient GITHUB_TOKEN, then trace the CLI startup and self-update GitHub fetch paths mentioned in the report. Inspect how token authentication errors and cached resources are handled; done means startup and self-update continue with a clear warning or viable fallback when the token returns 401/403.