Show CLI execution context at startup

[beyondszine]

Summary

Two hardening changes to the CLI diagnostic log — no new commands or panels.

1. Secret redaction in the log separator

Each run writes a separator block to the log so operators can find where it begins.
That block included the raw command line, exposing values passed to secret options.

CommandStringHelper.FormatForDisplay() now replaces the value of any known secret
option (--client-secret, --idp-client-secret, --password, --token,
--access-token, --api-key, --refresh-token) with <redacted>, handling both
--opt value and --opt=value forms.

  ============================================================
- Command : a365 develop-mcp register-external-mcp-server --auth-type ExternalOAuth --idp-client-secret S3cr3t!Value
+ Command : a365 develop-mcp register-external-mcp-server --auth-type ExternalOAuth --idp-client-secret <redacted>
  Started : 2026-06-10 14:32:07
  ============================================================

2. Authentication context log line

AuthenticationService logs the resolved user (UPN) and tenant at Information
level when the auth context changes — extracted from the MSAL token's claims (upn
/ preferred_username / unique_name, tid), so it reflects who the command acts
as with no a365.config.json dependency and no credentials exposed. Deduplicated:
fires only when user or tenant changes within a run.

  # at default verbosity, the log previously had no who-am-I line (only a DBG line, below threshold):
- [2026-06-10 14:32:09.480] [DBG] Authentication required for Agent 365 Tools
+ [2026-06-10 14:32:09.512] [INF] Authentication context: API calls will use user alice@contoso.com in tenant 11111111-1111-1111-1111-111111111111

Files changed

File	Change
Helpers/CommandStringHelper.cs	New FormatForDisplay() with secret-option redaction
Services/AuthenticationService.cs	Auth-context line; thread-safe TryClaimContextChange dedup; reuses shared JwtHelper / TryExtractUpnFromJwt for claims
Program.cs	Separator uses FormatForDisplay(); environment read resolves config via ConfigService.GetConfigFilePath()
Tests/.../CommandStringHelperTests.cs	Both arg forms, false-positive guard, empty args
CHANGELOG.md	[Unreleased] section

Scoped out during review

An earlier az account show–based startup panel was removed — it re-read
a365.config.json, ran a subprocess per command, and could disagree with the MSAL
token. The JWT line above delivers the same operator-trust signal without those
costs. The (cached token | interactive sign-in) suffix was also dropped — token
persistence is delegated to MSAL's cache, so the CLI can't reliably tell the two
apart.

Testing

• dotnet build — 0 warnings, 0 errors
• dotnet test — 1902 passed, 12 skipped, 0 failed (full suite, after merging main)

[beyondszine]

@sellakumaran please review once & suggest accordingly.

[sellakumaran]

The body still says "Azure CLI user, tenant, subscription" but those are no longer printed. Update the description so reviewers and future readers see what the merged feature actually does. --

[sellakumaran]

Thanks for the rework @beyondszine — you've addressed every v1 blocking concern, added tests, fixed the lock pattern in AuthenticationService, and the CommandStringHelper for secret redaction is a nice utility. This is great.

Two architectural concerns left before I can sign off, both about scope.

1. The Execution Context panel re-exposes a365.config.json

The panel prints "Config: " / "Config: not found at " on every --verbose run (when config file is not there in local folder, initial state), and its tenant and agent-identity rows read from a365.config.json. We've been deliberately reducing the user-facing dependency on that file — not requiring it, not advertising it, and not treating it as the source-of-truth for who-am-I. This PR walks that direction back into the operator UX. The IConfigService.LoadAsync fix from v1 solved the correctness issue, but the panel still has to reach into the config file to populate its rows, so the underlying tension stays.

The good operator-trust signal is already in this PR — your JWT-derived line in AuthenticationService.LogAuthenticationContext ("Authentication context: API calls will use user X in tenant Y (cached token | interactive sign-in)"). That sources from the actual MSAL token, needs no file, and is the right feature for telling operators which identity their command is about to act under.

Also note that the current setup command (and I verified with clean up as well) prints the following info already:

2. Eight files for what is really one log line

If we drop the panel, the PR collapses to:

• Services/AuthenticationService.cs — the auth context line and JWT tenant claim extraction
• Helpers/CommandStringHelper.cs and its tests — keep, it is reused for the file-log separator at the top of Program.Main
• A small Program.cs change — just the file-log separator
• CHANGELOG.md

That is the lean version of the same feature.

Could you cut the Execution Context panel in this PR? Specifically:

• Services/ExecutionContextLogger.cs and IExecutionContextLogger
• Tests/Services/ExecutionContextLoggerTests.cs
• Tests/ProgramTests.cs (only tests the panel's ResolveConfigPath helper)
• The showContext gate and call site in Program.Main
• Program.ResolveConfigPath helper and the IExecutionContextLogger DI registration

Keep everything else. The PR then ships the JWT-based auth context line — the operator-trust signal the description was selling — without re-exposing a365.config.json or growing the surface to eight files for one log line.

Happy to LGTM the scoped-down version. The work you've already done is not wasted — the helper, its tests, and the auth-context plumbing all stay.

[sellakumaran]

See my last comment in PR