Every issue form sets the issue type it produces

## Summary

Set `type: Bug` on `bug-report.yml` and `type: Feature` on `feature-request.yml`, so every path through the chooser produces a typed issue, and decide whether the `enhancement` label still earns its place beside a type.

## Current behaviour

The repository gained three issue types on 2026-08-19: Task ("A specific piece of work"), Bug ("An unexpected problem or behavior"), and Feature ("A request, idea, or new functionality"). Nothing uses them. None of the last 18 issues carries a type, and issues filed through the existing forms come out untyped.

`type` is a top-level key in the Issue Forms schema: "The issue type that will be automatically added to issues created with this template." #689 sets `type: Task` on the work-item form it adds, leaving one of three forms classifying its output.

Both existing forms instead carry `labels`, `bug` and `enhancement` respectively, which is the taxonomy a type now models natively.

## Motivation

A type is filterable, shows on the issue itself, and is one field rather than a label convention each form has to remember. Leaving two of three forms untyped splits the tracker into typed and untyped halves, which is worse than either end state and gets harder to backfill as issues accumulate.

The label question follows from it. `enhancement` currently marks anything that is not a bug, which is what Feature and Task now distinguish between. Whether the label stays, narrows, or goes is worth settling once rather than per form.

## Approach and alternatives

- Add the `type` key to both forms and leave the labels alone, which is the smallest change and defers the label question.
- Add the key and drop the labels the type now covers, which risks breaking saved filters and the `no-issue-activity` automation if either keys off a label.
- Backfill types onto existing open issues as well, so the tracker is consistent rather than split by filing date.

## Scope

`.github/ISSUE_TEMPLATE/bug-report.yml`, `.github/ISSUE_TEMPLATE/feature-request.yml`

## Out of scope

`work-item.yml`, which #689 already types. Creating or renaming the types themselves.

## Acceptance criteria

- [ ] Filing through each form produces an issue carrying the matching type
- [ ] The decision on whether `enhancement` and `bug` labels stay beside the types is recorded, and the forms match it
- [ ] Whether existing issues get backfilled is decided rather than left open

## Related issues

- #689 adds the work-item form and set `type: Task` on it, which surfaced that the siblings set none.
- #691 asks a neighbouring question about whether the work-item and feature-request forms overlap.