Use GFM Alert syntax for discussion-to-issue fallback warning

[Copilot]

The fallback warning added to issues created when create-discussion fails due to permissions was using a plain blockquote, making it easy to overlook.

Change

Replaced the > **Note:** blockquote with a > [!WARNING] GFM Alert in the fallback note appended to the issue body:

> [!WARNING]
> This was intended to be a discussion, but discussions could not be created due to permissions issues. This issue was created as a fallback.
>
> Discussion creation may fail if the specified category is not announcement-capable. Consider using the "Announcements" category or another announcement-capable category in your workflow configuration.

This renders as a visually distinct warning block on GitHub rather than a plain indented paragraph, drawing appropriate attention to the fact that the issue is a fallback artifact.

Original prompt

When create-discussion fails to create a discussion with a permission issue and fallbacks to generate an issue, it should add a clear warning footer in the generate issue that explains what happened. There is already a message but it is too subtle. Use a GFM Alert syntax to draw attention.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[pelikhan]

Make sure the user is told to enable discussion and select an Announcement-like category. @copilot

[pelikhan]

@copilot use same style as firewall alert message

[Copilot]

Pull request overview

Updates the fallback warning appended to issues created when create-discussion fails (due to permissions) to use GitHub Flavored Markdown (GFM) Alert syntax so it’s more visually prominent.

Changes:

• Replaced the fallback note formatting from a plain “Note” blockquote to a > [!WARNING] GFM Alert in the generated issue body.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The fallback note now relies on GFM Alert syntax (> [!WARNING]), but existing tests only assert that the body contains the explanatory text. Add a test assertion that the created issue body includes the > [!WARNING] marker so this rendering/formatting change can’t silently regress.