New-issue view: validate the target repo and surface a named error — a typo'd default_repo fails opaquely

[mabry1985]

Problem

A user with a typo'd github.default_repo (e.g. protoLabs/protoAgent for protoLabsAI/protoAgent) gets an opaque failure from the "File a GitHub Issue" view — the gh API 404 isn't translated, so nothing tells them the repo name is wrong or where it comes from. Two duplicate bug reports landed on the wrong repo's tracker as a result (protoAgent#2134/#2135, 2026-07-22).

Proposed direction

• On submit failure, classify the gh error: a 404/unknown-repo becomes "repo X not found — check github.default_repo/repos in this agent's settings", not a raw API error.
• Cheap prevention: the view (or /api/…/meta) marks a configured repo unverifiable when a lightweight gh repo view probe fails, surfacing the warning BEFORE the user composes an issue.
• Settings-save validation for repos/default_repo is the deeper fix (fits the #2114-era settings work on the host side) — out of scope here.

Acceptance

• Submitting to a nonexistent repo shows the named, actionable error (which config key, which value).
• A valid repo submits exactly as today.
• No new host requirements.

Refs

protoAgent#2135 (the report), protoAgent#2134 (dup).