vault: move ghp policies to their own pre-apply PR (#122)

Ordered plugin add requires the config-write policy to be effective in a prior
apply before this PR writes ghp/config. Policies now live in #122; this PR is
resources-only (catalog entry, backend config, role, modules, config.hcl wiring).

policies/ghp/admin.yaml

@@ -1,37 +0,0 @@
-# Allow the vault deployer to manage the ghp token secrets engine: its
-# connection config (seeded service token) and its token-minting roles.
-#
-# Scoped to ghp/* only, and deliberately excludes ghp/creds/* - minting tokens
-# is for consumers, not the deployer. ghp has NO rotate endpoint, so unlike the
-# gitea/netbox engines there is no config/rotate grant here. The plugin-catalog
-# grant needed to import the plugin is the shared, sudo-protected wildcard in
-# policies/sys/plugins/catalog/admin.yaml (already covers this plugin), and
-# mounting the engine uses the deployer's existing sys/mounts/* access, so no
-# new catalog/mount grant is added here (mirrors the gitea/netbox engines).
----
-rules:
-  # Engine connection config (base_url, TLS, seeded service token).
-  - path: "ghp/config"
-    capabilities:
-      - create
-      - read
-      - update
-      - delete
-  # Token-minting roles.
-  - path: "ghp/roles/*"
-    capabilities:
-      - create
-      - read
-      - update
-      - delete
-      - list
-  - path: "ghp/roles"
-    capabilities:
-      - read
-      - list
-
-auth:
-  approle:
-    - tf_vault
-  k8s/au/syd1:
-    - woodpecker_terraform_vault

policies/ghp/creds/agent.yaml

@@ -1,13 +0,0 @@
-# Lets the agents AppRole mint ephemeral ghp agent tokens, so AI coding agents
-# authenticate to ghp as their own short-lived, least-privilege identity.
-# Reading ghp/creds/agent returns a lease-bound token scoped by the role
-# (token_type agent, contents:read). Mirrors the gitea/creds/unkin-agent binding.
----
-rules:
-  - path: "ghp/creds/agent"
-    capabilities:
-      - read
-
-auth:
-  approle:
-    - agents