The hackage environment restricts its token to v* tag deployments

## Summary

Restrict the `hackage` environment to deployments from `v*` tags, so the
Hackage-publishing token is only reachable from a release run.

## Motivation

`gh api repos/:owner/:repo/environments` reports the `hackage` environment with
an empty `protection_rules`. Any job in this repo that declares
`environment: hackage` can therefore read `HACKAGE_TOKEN`, from any ref. The
only thing currently keeping the token narrow is that just two jobs declare the
environment.

Note the shape of the fix here is deliberately *not* a required reviewer. Under
#161 the human gate is the release PR, and everything after the merge — tag,
candidate, publish — runs unattended by design. A required reviewer on this
environment would reintroduce a second approval on every release and defeat that.
Deployment branch and tag rules restrict *where* the token is reachable from
without adding a click.

## Scope

- In alunduil-infrastructure, add deployment tag rules to the `hackage`
environment limiting it to the `v*` pattern.
- Confirm no reviewer requirement is added.
- Verify a workflow run from a non-tag ref cannot read `HACKAGE_TOKEN`.

## Acceptance criteria

- [ ] The `hackage` environment declares a `v*` deployment tag rule.
- [ ] `terraform plan` shows the rule added and no other drift.
- [ ] A run on a branch ref declaring `environment: hackage` is blocked from
deploying.

## Additional context

- Surfaced while fixing #144, which put `environment: hackage` on the candidate
job and noted the reviewer-gating tradeoff.
- Spans a second repo (alunduil-infrastructure), per the repo settings convention.