The top-level prune step deleted the whole db/ folder before the
second step meant to keep db/migrations under it ever ran, so no
deploy has actually shipped migrations - the remote apply step was
running runMigrations.vbs against an empty migrations folder and
silently reporting nothing pending.

Also adds scripts/run-migrations-remote(-apply).ps1, a lighter
migrations-only counterpart to deploy-iis.ps1 for catching a
production schema up without redeploying app code - used just now to
patch prod after this bug meant it never received prior migrations.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

- .gitattributes + an explicit allow-list in build-release.ps1 assemble a
  clean release tree (app/, core/, public/, scripts/, db/migrations only) -
  anything not on the allow-list is deleted from the deploy, so a stray
  file added later can't ship to production by accident.
- public/web.config.production.template holds the production appSettings
  (DB path outside the deploy dir, Environment=Production, error logging on).
- deploy-iis.ps1 builds, zips, and scp's a release to the IIS host, then
  runs deploy-iis-remote-apply.ps1 there over ssh to swap in the new files,
  run migrations, and restart the site/app pool - the DB and error log live
  outside the deploy directory so a redeploy never touches them.
- Removed deploy-iis-git.ps1 and migrate_isbusiness_to_households.vbs,
  leftovers from a different template project that didn't apply here.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>