chore(m365): bump @azure/msal-node 3 -> 6

[ToddHebebrand]

Summary

• Bumps @azure/msal-node ^3.8.10 -> ^6.0.0 in apps/m365-communications-executor (there is no v4; upstream jumps 3 -> 5 -> 6).
• No code changes needed: the executor constructs ConfidentialClientApplication with only auth.{clientId, authority, clientCertificate} and calls acquireTokenSilent/acquireTokenByCode — confirmed by grep, none of the removed/relocated surface (proxyUrl, customAgentOptions, protocolMode, acquireTokenInteractive, loopbackClient, responseMode) appears anywhere in src/.

Why

Task 1.5 from the dependency-major-upgrades plan.

Verification

pnpm --filter @breeze/m365-communications-executor up @azure/msal-node@latest   # landed ^6.0.0
pnpm install --frozen-lockfile --offline                                          # lockfile consistent

cd apps/m365-communications-executor && npx tsc --noEmit                          # clean
cd apps/m365-communications-executor && npx vitest run src/microsoft/delegatedClient   # 1 file, 12 tests passed

grep -rn "proxyUrl|customAgentOptions|protocolMode|acquireTokenInteractive|loopbackClient|responseMode" apps/m365-communications-executor/src   # 0 hits

Executor image build + boot check (step 3):

docker build -f apps/m365-communications-executor/Dockerfile -t m365-comms-test .   # succeeded

No README documents a health endpoint standalone check, so per the brief's fallback I confirmed a clean boot instead of a full health-endpoint hit (full boot needs real Azure Key Vault + Postgres DSN, not available locally):

• docker run --rm m365-comms-test exits 1 silently (autostart path swallows the error into process.exitCode), as expected without real config.
• Ran node -e inside the built image directly against dist/config.cjs's loadExecutorConfig(): fails with the expected, clean M365_COMMS_CLIENT_ID is required — proves the module graph (msal-node included) loads without any import/require crash.
• Went further and directly constructed @azure/msal-node's ConfidentialClientApplication inside the built image with a dummy auth.{clientId, authority} (no cert): it resolved to @azure+msal-node@6.0.0 in node_modules/.pnpm and threw the expected ClientAuthError: invalid_client_credential — i.e. the v6 class itself loads and runs its own validation logic correctly, not just "the require didn't throw."
• Test image removed after (docker rmi m365-comms-test).

Review round 1 (commit d87053b)

Reviewer flagged that the original pnpm up had picked up ambient lockfile drift unrelated to this task (yaml 2.9.0->2.9.1, joi 17.13.7->17.13.8, hono 4.13.7 new, compression 1.8.2 new) that the first PR body didn't disclose.

Transitive drift: narrowed by resetting pnpm-lock.yaml to origin/main and regenerating lockfile-only against this branch's package.json:

git checkout origin/main -- pnpm-lock.yaml && pnpm install --lockfile-only
git diff origin/main -- pnpm-lock.yaml | grep -E "^[-+]  '?[a-z@][^ ]*@[0-9]"

Result — scoped to exactly the bumped package and its own true dependency, nothing else:

-  '@azure/msal-common@15.17.0':
-  '@azure/msal-node@3.8.10':
+  '@azure/msal-common@16.14.0':
+  '@azure/msal-node@6.0.0':

Re-verified after narrowing: pnpm install --frozen-lockfile --offline clean, cd apps/m365-communications-executor && npx tsc --noEmit clean, npx vitest run src/microsoft/delegatedClient — 1 file, 12 tests passed.

Concerns

None. Confident in this bump — no removed surface used, clean typecheck, clean test suite, the v6 ConfidentialClientApplication was directly exercised (not just imported) inside the built container image, and the lockfile diff is now scoped to exactly this task's own packages.

🤖 Generated with Claude Code

https://claude.ai/code/session_018cms2ECUY322qubUH3PmVA

[cloudflare-workers-and-pages]

Deploying breeze with    Cloudflare Pages

Latest commit:	d87053b
Status:	✅  Deploy successful!
Preview URL:	https://7536defe.breeze-9te.pages.dev
Branch Preview URL:	https://chore-deps-msal-node-6.breeze-9te.pages.dev

View logs