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.

[Adam-it]

@milanholemans I guess the related issue was quite old as I would say this command should now be spo web rule get not alert to follow the new naming convention we want to introduce, right?

[milanholemans]

Since alerts are EOL this month, I think naming it alert would not be really future-proof, indeed.

[mvanhorn]

Renamed to spo web rule get across source, tests, docs, and the sidebar in fc47dca, following the thread now that alerts are EOL. Build and the focused spec (8 tests) pass locally. If you would rather a different noun than rule, happy to adjust - the rename is mechanical.

[Adam-it]

@mvanhorn I forgot to mention that last time, sorry thats on me, but besides uing rule instead of alert it would be best if we would still keep the old naming as an alias
similar like we do in all other spo web rule.. commands
For example
https://pnp.github.io/cli-microsoft365/beta/cmd/spo/web/web-rule-list

in this case we should add an alias for spo web alert get

[mvanhorn]

No problem, and good call — added in a5b7447.

spo web rule get now returns [commands.WEB_ALERT_GET] from alias(), so spo web alert get keeps working. Followed the same shape as the other aliased commands: the constant in commands.ts, an ## Alias section in the docs page, and the two alias assertions in the spec.

Still in draft — say the word and I'll mark it ready.