feat: add AI-powered issue triage workflow

[ayeshurun]

📥 Pull Request

Adds an AI triage workflow using github/ai-assessment-comment-labeler that automatically triages issues labeled needs triage.

What it does: Selects a prompt based on issue labels (bug/question/enhancement), runs an AI assessment via GitHub Models (gpt-4.1), posts a comment, applies labels, and escalates to @microsoft/fabric-cli-dev when needed. Supports re-triage when authors respond.

✨ Description of new changes

Prompts (.github/prompts/): Three self-contained prompts with full CLI command reference, standards (PEPs, RFCs), and concise response guidelines. Each maps assessment categories to specific label actions (escalate, help wanted, auto-close, request feedback).

Phase control: SUPPRESS_LABELS and SUPPRESS_COMMENTS env flags allow gradual rollout — set both to false for production.

---

Examples

• Test triage issue [FEATURE] Improve MPE creation experience when user lacks AuthZ on target Azure resource #99:

### AI Assessment: Valuable Enhancement

This proposal directly addresses a usability gap in the managed private endpoint (MPE) creation flow. Handling a 401 Unauthorized during MPE status polling as a non-fatal, actionable state ("Pending") improves clarity and matches the experience of other Azure tools. The suggested message removes ambiguity and guides users when their principal lacks access to private endpoint connections. This approach maintains backward compatibility and avoids introducing breaking changes, as it only impacts post-creation status retrieval.

The design aligns with CLI conventions: error swallowing is justified when the underlying create operation is successful, and non-error status messaging is preferable to hard failures for expected authorization gaps. Mapping unverified status to "Pending" fits existing status semantics. The optional --no-status-check flag is a reasonable extension, but the proposed default behavior change already solves the core problem.

This enhancement is scoped, feasible, and will reduce support friction for common service principal scenarios.

**Next Steps**  
**📋 Backlog candidate** — This enhancement has been triaged and will be considered for the team's backlog.

---
> 💡 If this issue requires the team's attention and was not escalated, you can tag @microsoft/fabric-cli-dev to notify the team.

• Test triage issue [BUG] Folder #101:

### AI Assessment: Potential Bug

The described behavior indicates that `fab ls` is inconsistently handling workspace and folder paths. Listing the workspace root returns items as if they are recursively enumerated through subfolders, but listing a specific folder results in a path error. Per documented hierarchy and command reference ([Hierarchy docs](https://microsoft.github.io/fabric-cli/essentials/hierarchy/), [ls command doc](https://microsoft.github.io/fabric-cli/commands/fs/ls/)), the CLI should support listing valid folders without invalid path errors and not automatically recurse unless specifically commanded.

The invalid path error in CASE 2 suggests either incorrect parsing of folder paths or broken entity resolution logic, especially since the workspace path is accepted but folder paths are not. The recursive listing in CASE 1 deviates from standard `ls` utility conventions; items should not be flattened into compound names unless requested, and folders should be navigable directly.

Severity is elevated due to potential regression in folder path resolution and entity hierarchy traversal, affecting access to nested resources and breaking expected filesystem semantics.

**Next Steps**
**🔔 Escalated to team** — This issue requires team review and has been flagged for attention.

---
> 💡 If this issue requires the team's attention and was not escalated, you can tag @microsoft/fabric-cli-dev to notify the team.

• Test tirage issue [BUG] fab exists returns strings instead of booleans in --output_format json #107:

### AI Assessment: Potential Bug

The report describes a discrepancy between expected and actual output format for the `fab exists` command when `--output_format json` is specified. Boolean results are rendered as strings ("true" or "false") rather than native JSON boolean values (true or false). This behaviour diverges from conventional JSON serialization and creates downstream usability and interoperability issues, especially in automation and scripting environments.

The CLI documentation specifies that output format can be `json` or `text` (https://microsoft.github.io/fabric-cli/essentials/output_format/), implying strict compliance with JSON standards (RFC 7159/8259). Returning a string where a boolean is expected is inconsistent with standard JSON behavior and can cause logic errors in consumer scripts (e.g., treating "false" as truthy). The issue is plausibly reproducible given the provided steps and output samples.

This does not appear to be a misconfiguration or a documented CLI limitation. Correction may require changes in the result serialization logic to ensure type fidelity.

**Next Steps**

**🔔 Escalated to team** — This issue requires team review and has been flagged for attention.

---
> 💡 If this issue requires the team's attention and was not escalated, you can tag @microsoft/fabric-cli-dev to notify the team.