When using stacked PRs (e.g. via Graphite), PRs are initially created targeting a parent feature branch rather than the default branch (main). Once the parent PR merges, the PR is automatically retargeted to main.

Currently, Railway only triggers PR environment creation on the opened event. Since the PR didn't target the default branch at creation time, no environment is spun up. When the base branch later changes to main, Railway doesn't re-evaluate — so the PR never gets a preview environment.

Expected behavior: Railway should listen for the GitHub pull_requestedited event (specifically when changes.base is present) and create a PR environment if the new base branch matches the default branch.

Repro:

1. Create a stacked PR: feature-b → feature-a → main

2. Merge feature-a into main

3. feature-b gets retargeted to main (by Graphite, or manually)

4. No PR environment is created for feature-b

This is increasingly common as stacked PR tooling (Graphite, ghstack, git-town) gains adoption. Supporting the base branch change event would make PR environments work seamlessly with these workflows.