Restore ghp secret backend + roles (config now seeded) (#130)

## Why

Reverts the temporary removal in #129. That PR deleted the ghp backend + role
config YAMLs to unblock the `master` apply, which was failing with:

```
Error: no secret found at "kv/data/service/vault/au/syd1/secret_backend/ghp/config"
  from module.ghp_secret_backend["ghp"].data.vault_kv_secret_v2.config
```

The ghp config KV is now seeded: `kv/data/service/vault/au/syd1/secret_backend/ghp/config`
holds key `admin_token`, and the ghp service secret
`kv/kubernetes/namespace/ghp/default/app` carries the matching `service_token`.
With the KV populated, `data.vault_kv_secret_v2.config` resolves, so the ghp
secret backend + role can be created. The ghp module wiring, plugin
registration, and policies were never removed (they stayed on `master`), so
restoring these two YAMLs re-populates the `for_each` maps and instantiates the
backend + role against the seeded config.

## Changes

- Restore `config/ghp_secret_backend/ghp.yaml`.
- Restore `config/ghp_secret_backend_role/ghp/agent.yaml`.

Net diff vs `master` is exactly the re-addition of those two files
(byte-identical to their pre-#129 content, the mirror-inverse of #129).

## Sequence

Final step (4/4) of the remove -> grant write policy -> seed KV -> add-back
sequence: #129 (remove) -> #128 (grant) -> KV seed -> this PR (add back).

## Verification

- `tofu fmt` clean, `yamllint` passes (pre-commit hooks green), `terragrunt validate` succeeds (only unrelated `vault_kv_secret_v2` deprecation warnings).
- `tofu init` installs the `vault-secrets-ghp` provider with no plugin/catalog error.
- ghp config KV path confirmed seeded with `admin_token`, so the previously-failing data source now resolves.
- A full privileged `plan` is not runnable under the agent AppRole (it lacks the policy to mint the consul backend token), so the created/destroyed resource counts are not machine-confirmed here; the git diff is exactly the two file additions, so no config-driven destroys are introduced.
- Note: the ghp backend mount at apply requires the `vault-plugin-secrets-ghp` binary present on the OpenBao nodes (pre-existing Puppet-managed plugin).

Reviewed-on: #130
Co-authored-by: unkin-agent <unkin-agent@unkin.net>
Co-committed-by: unkin-agent <unkin-agent@unkin.net>

config/ghp_secret_backend/ghp.yaml

@@ -0,0 +1,15 @@
+# Mounts the ghp token secrets engine at "ghp" and writes its config.
+# The seeded ghp service token is sensitive and read from KV, not stored here:
+#   kv/service/vault/au/syd1/secret_backend/ghp/config
+#   -> key: admin_token (required) the shared ghpsvc_... service token
+#
+# admin_token is a static shared secret provisioned into KV by an operator. The
+# SAME token value must also be present in the running ghp deployment's accepted
+# service tokens (GHP_AUTH_SERVICE_TOKENS) so ghp ACCEPTS what this engine
+# PRESENTS. ghp has no rotate endpoint, so the engine never rotates it in place;
+# the mount uses ignore_changes=[admin_token], making the KV seed create-only
+# (re-reading a stale KV value never re-pushes it to a live mount).
+description: "ghp ephemeral scoped agent token engine"
+base_url: "https://ghp.unkin.net"
+tls_skip_verify: false
+request_timeout_seconds: 30

config/ghp_secret_backend_role/ghp/agent.yaml

@@ -0,0 +1,15 @@
+# Role minting ephemeral, scoped ghp agent tokens. Reading ghp/creds/agent mints
+# a lease-bound token deleted from ghp on revoke/expiry. token_type "agent" binds
+# the minted token to a ghp App installation, so installation_id is REQUIRED.
+#
+# installation_id below is a PLACEHOLDER (0) and MUST be set to the real ghp App
+# installation id before this role can mint usable tokens. scopes are ghp
+# permission:level pairs; contents:read is the least-privilege default.
+---
+token_type: agent
+installation_id: 0 # PLACEHOLDER - set to the real ghp App installation id
+scopes:
+  - contents:read
+session_prefix: vault
+ttl: 3600      # 1h
+max_ttl: 86400 # 24h