Summary

Fixes #14703.

gh issue create --type <name> resolved the type name only after api.IssueCreate had run. On a repository that has no issue types (all user-owned repositories, where repository.issueTypes is null) or with a misspelled name, the issue was created and then the command exited 1 without printing its URL, so scripts retried and filed duplicates.

This resolves --type before the mutation:

// Resolve --type before creating the issue. An unknown type used to be
// reported only after api.IssueCreate had run, so the issue existed but
// its URL was never printed and the command exited 1, which made
// automation retry and file duplicates. Nothing here depends on the new
// issue, and the interactive flow already holds the selected ID.
if opts.IssueType != "" && opts.issueTypeID == "" {
	opts.issueTypeID, err = issueShared.ResolveIssueTypeName(apiClient, baseRepo, opts.IssueType)
	if err != nil {
		return
	}
}

Notes on the shape of the fix:

• It is placed in createRun immediately before api.IssueCreate, in the SubmitAction branch, so the preview/--web paths are untouched.
• The opts.issueTypeID == "" guard means the interactive flow keeps reusing the ID it already resolved at the prompt (create.go:377), so no duplicate RepositoryIssueTypes query is introduced.
• deferredUpdateIssueOptions still resolves --type as a fallback for callers that arrive without a resolved ID; its comment now says so.

I took the first of the two options in the issue ("Resolve --type before api.IssueCreate") rather than printing the URL and warning, because the unknown-type case is a user error that should have no side effects at all, and #13899 already covers the deferred-mutation error path for permission failures.

Tests

Test_createRun/create_with_type_not_found previously stubbed mutation IssueCreate before query RepositoryIssueTypes, which pinned the reported ordering. That stub is now gone:

// No IssueCreate stub: an unresolvable type must fail before the
// mutation, otherwise the issue exists but its URL is never printed
// and automation retries, filing duplicates.

The case still expects type "Bugz" not found; available types: Bug, Feature, Task, and the registry's Verify still requires the types query to have run. With the stub absent, any attempt to create the issue fails the test instead of passing silently — which is exactly the property the issue asks for.

Verification

go build ./...                              exit 0
go vet ./pkg/cmd/issue/create/              exit 0
gofmt -l pkg/cmd/issue/create/              no output
go test ./pkg/cmd/issue/...                 all 23 packages ok
go test ./pkg/cmd/issue/create/             ok
golangci-lint run ./pkg/cmd/issue/create/...    0 issues (v2.14.0, the version pinned in .github/golangci-lint-version)

Mutation check: flipping the new guard off (if false && …) makes Test_createRun/create_with_type_not_found fail, because IssueCreate is then attempted and no stub matches:

Error: Error message not equal:
  expected: "type \"Bugz\" not found; available types: Bug, Feature, Task"
  actual  : "Post https://api.github.com/graphql: no registered HTTP stubs matched …mutation IssueCreate…"

So the test genuinely detects the reported behaviour, rather than merely passing.

Out of scope, same class, happy to follow up

--parent, --blocked-by and --blocking are still resolved after api.IssueCreate in deferredUpdateIssueOptions, so an unresolvable reference there has the same "issue created, URL not printed, exit 1" shape. I kept this PR to --type so the change stays reviewable and each of those flags can get its own test; say the word and I will follow up with the same treatment for all three.