feat(labels): recover missing issue types from recognized form structure #1972

Existing Issue Search

Searched open and closed issue titles for label/form tracking and found no equivalent follow-up. This extends merged #1966 / PR #1969, whose scope intentionally covers status only.

🔍 Observed Consequence

Issues #1967 and #1961 have current Bug Report form-shaped bodies but no labels and no labeled/unlabeled events. In #1963, type:bug and status:needs-review were added manually after creation. Current remote forms declare canonical labels, and those labels exist. The cause of missing native labels is not established; form-shaped text is not proof of web-form submission.

💡 Desired Outcome

When a newly opened issue lacks a type:* label, recognize an unambiguous structure from one of the four current repository forms and add the corresponding type:bug, type:feature, type:docs or type:question. Preserve every existing type, status and unrelated label. Unknown, incomplete or ambiguous structures must not receive a guessed type. Do not classify from the title or semantic content.

Retain the merged status fallback independently: add status:needs-review only if no current status:* exists. An existing status must not prevent recovery of a missing type, and an existing type must not prevent recovery of a missing status.

📦 Affected Area

Other — GitHub issue labeling workflow.

Release Context

Default-branch workflow configuration after PR #1969; not release-specific.

🔄 Workarounds and Constraints

Manual labels currently repair missed type classification. Keep existing forms unchanged. Trigger only on issue opening; no backfill, later-label-removal handling, priority/effort inference, AI classifier, approval inference or singleton reconciliation.

📎 Additional Context

Approved scope in conversation: user requested bug/docs/etc. labeling and confirmed proceeding with deterministic structure-based recovery ("sip, hagamos eso"). Implement with test-first evidence for all four forms, unknown/ambiguous input and existing labels; test actual workflow behavior, update contributor docs, preserve minimum permissions and untrusted-input safety, and obtain independent verification for the write-capable workflow. Native GitHub label application remains a separate GET/add transaction; retain the documented non-atomicity limitation.