Full sync always reads configs from the default branch of the admin repo

Scheduled syncs (`CRON`) and full syncs (`full-sync.js`) always read `settings.yml`, suborg and repo configs from the default branch of the admin repo. `syncInstallation` in `index.js` builds its context without a ref, so `ConfigManager` and `Settings` fall back to the default branch.

There is no way to point a full sync at a branch of the admin repo. That matters mostly for dry runs: with `FULL_SYNC_NOP=true` you would want to run the plan against a config branch *before* merging it, but the sync silently uses the default branch instead, so the plan tells you nothing about your proposed change. @seanuleh ran into exactly this in the #818 discussion ("this isn't even running against the PR ref... only against the default branch of ADMIN_REPO").

Webhook-triggered PR checks do this correctly (the check run passes `pull_request.head.ref`); it's only the scheduled/CLI path that can't.

**Proposal**: a `CONFIG_REF` environment variable that `syncInstallation` passes through as the ref, defaulting to today's behavior when unset.

Start with syncInstallation in index.js and the scheduled/CLI path in full-sync.js, then trace how ConfigManager and Settings receive the admin-repository ref. Compare this with the webhook-triggered check path that passes pull_request.head.ref. Run a dry run with FULL_SYNC_NOP=true against a non-default config branch and confirm the plan uses that branch while unset behavior remains unchanged.

Written by the indexing model from the issue text.