Stop-WebAppPool only requests a stop - the w3wp.exe worker process can
keep running for a few seconds afterwards, still holding the site's
files open, so the previous fix (stopping both sites before the wipe)
wasn't sufficient on its own.

- Wait-AppPoolFullyStopped: polls app pool state until Stopped (30s
  timeout), then force-kills any lingering w3wp.exe for that pool
- Remove-DirectoryContentsWithRetry: retries the wipe a few times with
  a short delay, since file handles can take a moment to release even
  after the worker process is confirmed gone

The admin site's physical path lives inside RemoteDir (RemoteDir\public-admin).
On a redeploy it was still running while RemoteDir was wiped, so IIS held its
files open and Remove-Item failed with Access is denied. Now both the public
and admin site/app pool are stopped up front, before the wipe.

- New AdminOrdersController + view: table of Orders with search by
  email/jurisdiction #, pagination (20/page), and per-row mailto link
  to resend the order-continue URL
- OrdersRepository: add GetAll() and SearchPaged() (LIKE search,
  PagedQuery-based pagination)
- MailtoEncode helper added to core/helpers.asp (mailto-safe URL
  encoding: %20 not +)
- Controller registered in autoload + ControllerRegistry
- public-admin/ folder: dedicated Default.asp routes, web.config with
  192.168.1.0/24 ipSecurity, production template with same restriction
- applicationhost.config: second IIS Express site (Admin Web Site,
  port 8081)
- run_site.cmd: launches both sites (public in separate window,
  admin in foreground)
- build-release.ps1: public-admin in allow-list, swaps its
  web.config from production template
- deploy-iis-remote-apply.ps1: optional admin site/app-pool config
  + restart
- deploy-iis.ps1: -AdminSiteName/-AdminAppPool/-AdminBaseUrl params,
  admin smoke test

- scp/ssh now force a fallback to password auth so a missing/rejected
  key fails with a real prompt instead of an opaque "Permission denied
  (publickey)".
- Smoke test now checks each path against its expected status (/404 is
  expected to 404) instead of treating any non-throwing response as a
  pass, and surfaces the actual failure reason.
- The remote IIS server has the 64-bit Access Database Engine, unlike
  the local dev machine, so its app pool stays 64-bit and migrations
  run through the plain (64-bit) cscript.exe instead of SysWOW64.

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>