docs: clarify -BearerToken/-Token examples accept both "Bearer <token>" and raw token forms

[pavankadabala-png]

Updates the LCS cmdlet comment-based-help examples to reflect how the token parameters actually behave, per the revised scope of #666.

Background: the original issue reported that the Bearer prefix in the -BearerToken/-Token examples caused auth errors. On closer investigation (thanks @FH-Inway), the public LCS cmdlets normalize the token — a StartsWith("Bearer ") guard auto-prepends Bearer when it's missing — so both "Bearer <token>" and "<token>" are valid and produce the same result.

Public cmdlets (Invoke-D365LcsUpload, Get-D365LcsDeploymentStatus, Invoke-D365LcsDeployment): rather than removing the prefix, the examples now show both forms are accepted. Each gets a second .EXAMPLE using the Bearer -prefixed token, and the .PARAMETER BearerToken description notes the prefix is optional and prepended automatically when missing.

Internal functions (Start-LcsUploadV2, Complete-LcsUploadV2, Get-LcsDeploymentStatusV2, Get-LcsEnvironmentHistory, Get-LcsEnvironmentMetadata, Start-LcsDeploymentV2): these have no normalization and always require the prefix, so their examples keep the Bearer <token> form (restored to match the internal API contract). This leaves them identical to master, so they no longer appear in the diff.

Consistency check: all 16 public LCS cmdlets that send a token to the API already carry the StartsWith("Bearer ") guard. The only token-parameter cmdlet without it is Set-D365LcsApiConfig, which just stores the token in config and never calls the API, so it doesn't need normalization.

Only .EXAMPLE / .PARAMETER help text changed — no functional/normalization code was touched.

Closes #666

[FH-Inway]

@pavankadabala-png Not sure if you saw the comment on the issue: #666 (comment)
Let me know if you are interested in working on this changed issue scope.

[pavankadabala-png]

Thanks @FH-Inway, no problem on the scope change — happy to take it on.

Here's the plan:

• Public LCS cmdlets (the ones with the StartsWith("Bearer ") normalization): instead of dropping the prefix, I'll show both forms work — one .EXAMPLE with -BearerToken "Bearer Jldjfaf..." and one with -BearerToken "Jldjfaf...", plus a .PARAMETER note that the Bearer prefix is optional and gets prepended automatically when missing.
• Internal functions (Start-LcsUploadV2, Complete-LcsUploadV2, Get-LcsDeploymentStatusV2, Get-LcsEnvironmentHistory, Get-LcsEnvironmentMetadata, Start-LcsDeploymentV2): no normalization here, so they always need the prefix. I'll put Bearer back in their -Token/-BearerToken examples.
• On the consistency question: all 16 public LCS cmdlets that send a token to the API already have the StartsWith("Bearer ") guard, so that's consistent. The only token-parameter cmdlet without it is Set-D365LcsApiConfig, which just stores the token and never calls the API, so it doesn't need normalization.

Pushing the updated commits shortly.