Path-based selective build triggering for monorepo apps in Amplify Hosting

### Before opening, please confirm:

- [x] I have checked to see if my question is addressed in the [FAQ](https://github.com/aws-amplify/amplify-hosting/blob/master/FAQ.md).
- [x] I have [searched for duplicate or closed issues](https://github.com/aws-amplify/amplify-hosting/issues?q=is%3Aissue+).
- [x] I have removed any sensitive information from my code snippets and submission.

### Amplify Hosting feature

Build settings

### Is your feature request related to a problem? Please describe:

We have a monorepo with 5 Amplify Hosting apps, each connected to the same
GitHub repository with distinct appRoot paths (packages/next, packages/cmbs,
packages/cre, packages/lv, packages/dm).

Currently, every push or pull request to the repository triggers a build
pipeline for ALL 5 connected Amplify apps — regardless of which packages
actually changed. This causes the following problems:

1. UNNECESSARY BUILDS ON PULL REQUESTS
When a change is made to only one app (e.g., packages/cre), all 5 Amplify
apps initiate a pipeline. Although AMPLIFY_DIFF_DEPLOY=true skips the build
step for unchanged apps, the pipeline still initiates (clone, cache
retrieval) adding ~6-10 seconds of overhead per app on every PR.

2. NOISY PR PREVIEW DEPLOYMENTS
Amplify generates preview deployments and posts GitHub PR comments with
preview URLs for ALL connected apps — including apps whose code has not
changed. This creates confusion during code reviews as reviewers see 5
preview URLs when only 1 app was modified.

3. ALL APPS DEPLOY ON MERGE TO MAIN
When a PR is merged, all 5 apps trigger production deployments
simultaneously in a non-deterministic order. This means the app that
actually contains changes is not guaranteed to deploy first, increasing
time-to-availability. Total deployment time currently exceeds 20 minutes
in some cases.

### Describe how you'd like this feature to work

We would like Amplify Hosting to support path-based selective build triggering
for monorepo setups. Specifically:

1. PATH-BASED WEBHOOK FILTERING
Allow each Amplify app to define one or more watch paths. Only trigger a
build pipeline when a push or PR contains changes within those paths.

Example configuration in amplify.yml:

applications:
- appRoot: packages/cre
watchPaths:
- packages/cre/**
- packages/shared/**
frontend:
...

2. SELECTIVE PR PREVIEWS
Only generate PR preview deployments and post GitHub PR comments for apps
whose watchPaths contain changes. Apps with no relevant changes should not
initiate a pipeline, generate a preview URL, or post a GitHub comment.

3. MULTIPLE PATHS FOR AMPLIFY_DIFF_DEPLOY_ROOT
Allow AMPLIFY_DIFF_DEPLOY_ROOT to accept a comma-separated list of paths
so apps that depend on shared packages can monitor multiple directories:

AMPLIFY_DIFF_DEPLOY_ROOT=packages/cre,packages/shared

4. DEPLOYMENT ORDERING (NICE TO HAVE)
Provide a way to define deployment priority across apps in the same
repository so the most critical or most recently changed app deploys first.

**Current Workaround**

Since these features are not natively available, we implemented a GitHub
Actions workflow to replace Amplify's native webhook triggers:

Step 1 — Disable Amplify's native triggers:
- Disabled auto-build on all Amplify apps via:
aws amplify update-branch --no-enable-auto-build
- Disabled PR previews on all Amplify apps via:
aws amplify update-branch --no-enable-pull-request-preview

Step 2 — GitHub Actions workflow (.github/workflows/amplify-selective-build.yml):
- Uses dorny/paths-filter to detect which packages/* directories changed
- Includes packages/shared as a dependency for all apps
- On PR opened/updated:
* Creates an Amplify branch using the source git branch name
* Calls aws amplify create-branch + start-job ONLY for changed apps
* Preview URL: https://..amplifyapp.com
- On PR closed:
* Calls aws amplify delete-branch to clean up preview branches
- On push to main:
* Calls aws amplify start-job --job-type RELEASE ONLY for changed apps

This workaround is functional but adds operational overhead:
- Requires managing AWS credentials as GitHub secrets
- Requires IAM permissions: StartJob, CreateBranch, DeleteBranch, GetBranch
- Does not replicate Amplify's native GitHub status checks on PRs
- Requires manual updates when new apps are added to the monorepo
- Adds workflow maintenance burden that should not be necessary

Native support for path-based filtering in Amplify Hosting would eliminate
this workaround entirely and significantly improve the developer experience
for teams working with monorepos.

Repository structure for reference:

```
├── amplify.yml
├── node_modules
├── package-lock.json
├── package.json
├── packages

packages
├── cmbs
│ ├── app
│ ├── package.json
│ ├── public
│ └── src
├── cre
│ ├── app
│ ├── package.json
│ ├── public
│ └── src
├── dm
│ ├── app
│ ├── package.json
│ ├── public
│ └── src
├── lv
│ ├── index.html
│ ├── package.json
│ ├── public
│ ├── src
│ └── vite.config.js
├── next
│ ├── app
│ ├── package.json
│ ├── public
│ └── src
└── shared
├── package.json
└── src
```

Start by reviewing the requested amplify.yml watchPaths configuration and the .github/workflows/amplify-selective-build.yml workaround described in the issue. Trace how Amplify currently triggers branch and pull-request builds, then define the affected configuration and deployment paths; done means unchanged apps do not start pipelines or previews, while changes to watched or shared paths trigger the appropriate apps.

Written by the indexing model from the issue text.