Adds 'spo web alert get' command. Closes #6862

[mvanhorn]

Closes #6862

Adds the spo web alert get command, which retrieves the details of a specific alert from a SharePoint site list.

The command accepts the SharePoint site URL (-u, --webUrl) and the alert GUID (--id), and calls Web/Alerts/GetById('<id>') expanding List, User, and List/Rootfolder so the returned payload exposes the list title, root folder path, and user principal name alongside the core alert fields.

Follows the existing spo web alert list / spo web alert remove command structure:

• src/m365/spo/commands.ts (registers WEB_ALERT_GET)
• src/m365/spo/commands/web/web-alert-get.ts
• src/m365/spo/commands/web/web-alert-get.spec.ts
• docs/docs/cmd/spo/web/web-alert-get.mdx
• docs/src/config/sidebars.ts

[milanholemans]

@mvanhorn, please respect our way of working and ask us to assign an issue before working on one. This will prevent two contributors from working on the same issue.
We appreciate the work you do, but respect our rules. It's already the third time we have to remind you of this.

[milanholemans]

If you've fixed the pipeline issue, you can reopen this PR.

[mvanhorn]

@milanholemans you're right, and I owe you a real apology. @Jwaegebaert flagged the same thing on #7221 two days ago and I said I'd claim issues before working on them. Then I opened this PR without doing that. That's a broken commitment, not a misunderstanding.

I've pushed a fix for the failing test (the 'sets telemetry properties' assertion was wrong - getTelemetryProperties skips required options, so it could never return true for id/webUrl) and squashed to a single commit per the One PR = One Commit convention.

I'm going to pause any new PRs to this repo until I can be sure my workflow actually claims the issue first. If you'd prefer I close this one rather than reopen, I'm happy to do that too - your call.