"Migrate to our GitHub App" reports success but does not change app wiring; `update-app --access-token` mints an SSH deploy key instead of using the GitHub App

## Summary

On a CloudFormation-created Amplify Hosting app (`AWS::Amplify::App` with `AccessToken`), the console's **"Migrate to our GitHub App"** action reports **"repository migrated"** and updates the app's `updateTime`/`webhookCreateTime`, but the build wiring is unchanged — builds continue to clone over SSH using the read-only deploy key, and the legacy repository webhook is left in place.

Subsequently calling `update-app --access-token ` — documented as the parameter that "authorize[s] access to a GitHub repository using the Amplify GitHub App" — **mints a new read-only SSH deploy key** instead, and flips `repositoryCloneMethod` from `TOKEN` to `SSH`.

Net effect: there appears to be no working path from a CFN-created app to GitHub App wiring, and the console reports success for an operation that has no effect.

## Environment

- Amplify Hosting, `WEB_COMPUTE` platform (Next.js SSR), us-east-1
- App created via CloudFormation `AWS::Amplify::App` with the `AccessToken` property (classic PAT)
- `aws-amplify-us-east-1` GitHub App **is** installed on the org, with the repository in its selected-repositories set
- Private repository in a GitHub organization

## Steps to reproduce

1. Create an Amplify app via CloudFormation `AWS::Amplify::App`, supplying `AccessToken` (a classic PAT with `repo` scope) and a GitHub repository URL.
2. Run a build. Note the build log line: `# Cloning repository: git@github.com:/.git` — SSH, via an auto-minted read-only deploy key.
3. Install the `aws-amplify-us-east-1` GitHub App on the org and ensure the repository is in its selected set.
4. In the Amplify console, use the **"Migrate to our GitHub App"** banner → Start migration → Complete. The console reports **"repository migrated"**.
5. Trigger a new build (`start-job --job-type RELEASE`).

## Expected

After a successful migration, builds clone over HTTPS using a short-lived GitHub App installation token, the read-only deploy key becomes unused, and the legacy repository webhook is replaced.

## Actual

The clone line is byte-identical before and after migration across four builds:

```
job 11 (pre-migration) # Cloning repository: git@github.com:/.git
job 12 (+26s post-migration) # Cloning repository: git@github.com:/.git
job 13 (+24m post-migration) # Cloning repository: git@github.com:/.git
job 14 (post update-app) # Cloning repository: git@github.com:/.git
```

Job 13 was run 24 minutes after the migration, ruling out a propagation delay.

Also unchanged after migration:

- The read-only deploy key `:amplify@aws` remained present and in use.
- The repository webhook to `amplify-webhooks.us-east-1.amazonaws.com/github/repository-webhook` was untouched — GitHub reports `created_at == updated_at ==` the original app-creation time.

The app record *was* modified — `updateTime` and `webhookCreateTime` were both stamped at the moment of the migration click — so the action was accepted and had some server-side effect, just not on the clone path.

### `update-app --access-token` also does not work

Per `aws amplify update-app help`:

> `--access-token` — The personal access token is used to authorize access to a GitHub repository **using the Amplify GitHub App**.
> `--oauth-token` — The OAuth token is used to create a webhook and a read-only deploy key **using SSH cloning**.

Calling `update-app --access-token ` produced the `--oauth-token` behaviour: a **new read-only deploy key** was minted (timestamp matches the API call to the second), and `repositoryCloneMethod` changed `TOKEN` → `SSH`. The next build still cloned over SSH.

## Impact

1. A control that reports success while having no effect is actively misleading. Following the documented post-migration cleanup — "verify the legacy webhook is replaced, then delete the orphaned deploy key" — would delete a **load-bearing** key and break the build pipeline. This was only caught by diffing the clone line against a pre-migration baseline.
2. There appears to be no path from a CFN-created app to GitHub App wiring, which matters for anyone provisioning Amplify apps as infrastructure-as-code and then hardening the GitHub connection.

## Questions

1. Is migration to the GitHub App supported for apps created via CloudFormation with `AccessToken`? If not, the console should not offer the banner or report success.
2. Is there a supported way to move an existing app onto GitHub App wiring, or must the app be recreated?
3. Should `update-app --access-token` result in GitHub App wiring as documented? The observed behaviour contradicts the CLI documentation.

Account ID, app ID and full build logs available on request.

Start with the CloudFormation AWS::Amplify::App AccessToken setup, the console’s “Migrate to our GitHub App” action, and the `update-app --access-token` entry point. Reproduce the migration and compare `repositoryCloneMethod`, build clone lines, deploy keys, and repository webhooks; done means the supported behavior and any required correction or documentation are established.

Written by the indexing model from the issue text.