Configurable Issue Types model (GitHub issue type + labels + body template)

Review popup/app.html and issue-form.js, then trace the generated type selector and submit flow. Verify in the browser that Bug, Enhancement, and Other produce the expected type, labels, and body URL parameters, including graceful handling when GitHub issue types are unsupported. Done means the acceptance criteria pass without storage persistence or regressions.

Story:

As a User/Developer
I want issue "types" to be a structured data model — each mapping to a GitHub native issue type, default labels, and a body template
So that selecting a type prefills the right fields and the concept is no longer hardcoded across the popup

Requirements:

• Today the type radio value (bug/enhancement/other) is overloaded: it's used both as the label and to pick a hardcoded body template, with the radios hardcoded in popup/app.html. This issue decouples that into a real model.
• Define a Type shape { id, name, githubType, labels[], bodyTemplate }:
  • name — display name (e.g. "Bug")
  • githubType — free-text, sent as &type= (confirmed working live, e.g. &type=Bug); org-level feature so it must be ignored gracefully off-org
  • labels — array of default labels, joined into &labels=
  • bodyTemplate — markdown body
• The default types (Bug / Enhancement / Other) live in code as the single source of truth — not seeded into chrome.storage. Keeping them code-owned means we can improve them and every user on the defaults gets the update, with no migration. User-added types & their persistence are deferred to #15.
• Adopt the improved feature template (Story → Requirements → Tasks → Acceptance criteria).
• Wire the selected type into the redirect URL: &type=, &labels= (supports multiple), and the body template — preserving the existing pure-redirect UX.
• Rename the internal type / type_field concept consistently.

Tasks:

• Define the Type shape + the code DEFAULTS (Bug / Enhancement / Other) as the single source of truth — no storage, no seeding
• Render the type selector from the model (replacing the hardcoded radios in app.html), via DOM APIs + .text()
• Refactor the submit handler to build the URL (&type=, &labels=, body) from the selected type
• Adopt the updated feature template
• Keep field-state persistence working with the generated radios — the existing generic radio handler in issue-form.js is reused; radios render synchronously, before IssueForm.init

Acceptance criteria:

• Selecting Bug yields &type=Bug (where supported), the bug label(s), and the bug body template
• A type can carry multiple labels, all applied via &labels=
• githubType is sent as &type= and is gracefully ignored off-org (no broken URL)
• No behavioural regression vs the previous Bug/Enhancement/Other radios
• Type definitions come from the code DEFAULTS model (not inlined in the submit handler) and are not persisted to storage in this issue

Foundation for the Issue Types work (replaces ideas #1 + #3, merged). Storage/persistence intentionally deferred to #15.