fix(orb): issue-side new-account labeling uses a non-null assertion where the PR-side twin defensively falls back

[JSONbored]

⚠️ Definition of Done: this issue must be completed in full, in a single PR. Do not split this
work across multiple PRs, and do not defer any Deliverable below to a follow-up issue. A PR that
satisfies only some of the Deliverables, stubs a required test, or leaves a checkbox
partially-done does NOT resolve this issue and will be closed.

Context

RepositorySettings.newAccountLabel is typed as optional (newAccountLabel?: string,
src/types.ts:1279). The two PR-side call sites for this field
(src/queue/processors.ts:2765,3123) both handle the optional case defensively:
settings.newAccountLabel ?? "new-account", with a comment explicitly justifying the fallback.

The issue-side call site (src/queue/processors.ts:6742) instead uses a bare non-null assertion:
issueSettings.newAccountLabel!. Its own preceding comment (lines 6714-6715) claims "same contract
as the PR maintenance path" — but the implementation diverges: the PR path degrades gracefully to a
default label, the issue path would throw (or silently produce undefined as the label value,
depending on TypeScript's runtime behavior for the non-null assertion, which performs no actual
runtime check) if the field were ever undefined.

This is currently masked in practice because resolveRepositorySettings's database defaults always
populate this field today — but any settings-resolution path that doesn't apply that default (e.g. a
manifest overlay that omits the field, or a future settings source) will behave inconsistently
between the PR and issue paths: the PR path silently falls back to "new-account", the issue path
does not.

Requirements

• Change the issue-side call site to use the same defensive fallback as the PR-side twins:
  issueSettings.newAccountLabel ?? "new-account".
• Do not change the PR-side call sites (they are already correct).

Deliverables

• src/queue/processors.ts:6742's issue-side label resolution uses ?? "new-account" instead
  of a bare non-null assertion.
• A new test constructs settings with newAccountLabel explicitly undefined, fires an
  issues opened webhook for a below-account-age-threshold author, and asserts
  ensurePullRequestLabel/the equivalent issue-labeling call is invoked with "new-account" —
  currently invoked with undefined (or throws, depending on the exact runtime path).

Both Deliverables are required in the same PR.

Test Coverage Requirements

src/** is measured by codecov/patch (99%+ target, branch-counted). The new test must exercise
the previously-unhandled newAccountLabel: undefined branch on the issue-side path directly.

Expected Outcome

The issue-side new-account labeling path genuinely matches its own documented "same contract as the
PR maintenance path" claim, degrading gracefully to the default label instead of relying on a
non-null assertion that provides no actual runtime safety.

Links & Resources

• src/queue/processors.ts:6742 (the assertion to fix), :6714-6715 (the "same contract" claim)
• src/queue/processors.ts:2765,3123 (the already-correct PR-side twins)
• src/types.ts:1279 (RepositorySettings.newAccountLabel?: string)

[linear-code]

JSO-6032