Fix jira init 404 at configuring metadata step on Jira Cloud

[rethab]

Jira Cloud has deprecated the bulk `GET /issue/createmeta` endpoint (with the `expand=projects.issuetypes.fields` parameter) that `jira init` uses to fetch issue types. This causes the "Configuring metadata" step to fail with a 404 for genuine Cloud tenants, as reported by multiple users.

Jira Server 9+ hit the same deprecation earlier and was already worked around by using the newer per-project `GET /issue/createmeta/{project}/issuetypes` endpoint instead, but that code path was only enabled for local/on-prem installations.

This change routes Cloud installations through the same per-project endpoint. The issue type `id`/`name`/`subtask` data it returns is all `configureMetadata` actually consumes from the old bulk response — the `Fields` data fetched via the old endpoint's `expand` was never read downstream (custom field metadata is fetched separately via `GetField()` in `configureFields`), so this is a safe, no-new-endpoint substitution.

Adds a test verifying that a Cloud installation hits the new per-project endpoint instead of the deprecated bulk one.

Addresses ankitpokhrel#757.

[rethab]

Rebased onto current main (the conflict in internal/config/generator_test.go was both sides adding tests — kept both, and took the fork's import path).

One thing to fix before this merges: the per-project endpoint silently drops untranslatedName, so Cloud users lose Handle.

The PR body says the Fields data from the old expand was the only thing the bulk response carried that isn't used elsewhere. That's true of Fields, but not of the whole response — Handle goes missing too:

• internal/config/generator.go:657 sets Handle: it.Handle on the bulk path.
• configureIssueTypesForJiraServerV9 (internal/config/generator.go:685-690) doesn't, because CreateMetaResponseJiraServerV9.Values (pkg/jira/createmeta.go:29-33) has no untranslatedName field.

Handle isn't dead code — GetSubtaskHandle (internal/cmdutil/utils.go:171-178) and issue create (internal/cmd/issue/create/create.go:135,198,230,272) use it to send the untranslated issue type name. The field exists precisely for non-English Jira sites. So after this change, jira init against a translated Cloud site writes a config whose issuetypes have no handles, degrading issue create.

Cloud's IssueTypeIssueCreateMetadata does return untranslatedName, so the fix is small: add Handle string `json:"untranslatedName,omitempty"` to the V9 values struct and map it in the generator.

Smaller things, none blocking:

• generator_test.go:98 — t.Fatalf is called from the HTTP handler goroutine. t.Fatal* has to come from the test goroutine; elsewhere it calls runtime.Goexit on the wrong one. Use t.Errorf + w.WriteHeader(http.StatusNotFound).
• generator_test.go:115-117 — should be require, not assert. With the fix reverted the test doesn't fail cleanly, it panics with an index-out-of-range at :116, because assert.Len doesn't halt.
• The generator still passes Expand: "projects.issuetypes.fields" into the V9 request (generator.go:672-675), which is meaningless for that endpoint. Jira ignores it today, but it's misleading — consider dropping it.
• Pagination: the endpoint paginates (maxResults defaults to 50) and GetCreateMetaForJiraServerV9 neither sets it nor loops, so a project with >50 issue types is silently truncated. Pre-existing on the Server 9 path, but this change extends the exposure to every Cloud user. Fine as a follow-up.