Address PR review: PXE gate + callback, git-sync templates, distro catalog, k8s targets, http+https

Implements the six review comments on PR #1:

- Per-host PXE-enable gate: read NetBox pxe_enabled custom field; a known host
  with it false gets the safe local-boot script (Cobbler netboot_enabled). Add a
  token-guarded POST /provisioned/{ident} callback that clears pxe_enabled in
  NetBox, plus a %post snippet in the default kickstarts that calls it.
- Templates from a git repo: bootapi clones a templates repo and re-pulls every
  BOOTAPI_TEMPLATE_GIT_INTERVAL (default 3m), atomically swapping the template
  set (last-good kept on parse failure; embedded defaults are the startup
  fallback). Metrics for syncs/failures/generation.
- Distro catalog (catalog/*.yaml): NetBox host -> boot images/kickstart, so
  adding an OS is a YAML + template change. Ships almalinux + fedora entries
  (artifactapi remotes); debian/talos path documented.
- Boot images from the artifactapi almalinux/fedora remotes via the catalog.
- Bind resolvers, puppet server/CA and PUPPETCA_URL env file now target the k8s
  services (198.18.200.7; puppet(ca).k8s.syd1.au.unkin.net).
- Boot path served over plain HTTP (installers lack CA trust) with an optional
  parallel HTTPS listener; docs say do not 301 the boot endpoints.

New packages: internal/catalog, internal/gitsync. NetBox client gains a
pxe_enabled write (token needs that scope - noted in docs). `bootapi validate`
subcommand validates a template/catalog set for the templates-repo CI.

go build/vet clean, go test -race green, golangci-lint v2 clean, pre-commit clean.

Claude-Session: https://claude.ai/code/session_015ur3i7D2azsMAWTSVABApv

docs/security.md

@@ -15,6 +15,7 @@ render time from Vault/env.**
 | template selection knobs (`provision_template`, `nameservers`, `gateway`) | NetBox custom fields | `.Custom` / typed fields |
 | **root password hash** | Vault → `BOOTAPI_ROOT_PASSWORD_HASH[_FILE]` | `.RootPasswordHash` |
 | **SSH authorized keys** | Vault → `BOOTAPI_SSH_AUTHORIZED_KEYS` | `.SSHAuthorizedKeys` |
+| **provision token** | Vault → `BOOTAPI_PROVISION_TOKEN[_FILE]` | `.ProvisionToken` |
 | puppet CA/server names | env (not secret) | `.PuppetServer` / `.PuppetCAServer` |
 
 `BOOTAPI_ROOT_PASSWORD_HASH_FILE` and `BOOTAPI_NETBOX_TOKEN_FILE` let the values
@@ -38,6 +39,30 @@ secret, never in the NetBox/inventory layer.
   the puppetmaster autosigns it based on source subnet + `*.main.unkin.net`
   (unchanged from Cobbler). So the kickstart carries no puppet secret.
 
+## The provisioned callback token
+
+`POST /provisioned/{ident}` (which flips `pxe_enabled` off in NetBox) is guarded
+by `BOOTAPI_PROVISION_TOKEN`. The default kickstart `%post` calls it with that
+token in an `Authorization: Bearer` header, so **the token is embedded in every
+rendered kickstart** — treat it as a provisioning secret (same exposure class as
+the root hash: visible to anything on the provisioning VLAN). It only authorizes
+clearing a boot gate, not reading data. Rotate it in Vault as normal; empty
+disables the callback (fail closed). The call runs over plain HTTP by default
+because `%post` has no internal-CA trust yet; the token — not TLS — is what
+authenticates it.
+
+## NetBox write scope
+
+bootapi performs exactly one NetBox write: `PATCH /api/dcim/devices/{id}/` setting
+`custom_fields.pxe_enabled=false` from the provisioned callback. Its NetBox token
+therefore needs **write on the device `pxe_enabled` custom field** in addition to
+read on devices/interfaces/ip-addresses. Scope the `bootapi` NetBox
+role/permission to just that (a NetBox object-permission constrained to
+`dcim.device` with the `pxe_enabled` field) rather than granting broad write.
+This is a deliberate, minimal escalation from the read-only design; it is called
+out here and in the deployment doc so the token is provisioned with the right
+(and only the right) scope.
+
 ## Follow-up: per-template Vault lookups
 
 Today all render-time secrets are process-wide env/files (one root hash, one key