feat(onboarding): admin-consent link + bring-your-own-app guidance + restart-after-az-login

[Gregory Joseph (gnjoseph)]

Implements the owning-app consent & bring-your-own-app onboarding improvements from the PR #3 review.

What changed

1. Copy-paste admin-consent link (src/tools/create-app.ts)

After the owning app is created (or reused) and its SPE permissions are requested, the tool output now appends a Grant admin consent section with a copy-paste tenant-wide admin-consent URL:

https://login.microsoftonline.com/{tenantId}/adminconsent?client_id={appClientId}

• {tenantId} = the real signed-in tenant id (identity.tenantId); {appClientId} = the newly created/reused app's public client id (app.appId).
• If you are a Global Administrator — opening the link grants consent for the entire tenant in one step.
• If you are NOT an admin — copy the link and send it to your tenant admin to grant consent on your behalf.
• Non-blocking / informational: no browser is opened, provisioning is not gated on consent, and nothing throws. The URL contains only the tenant id + public client id — never a token/secret.
• Surfaced on both the create and reuse paths (a reused app may have just had permissions re-requested best-effort, so consent can still be pending).
• Missing-tenant fallback: if the tenant id is genuinely unavailable, the link targets organizations and the section notes it.

2. Skill reference removed (src/tools/create-app.ts)

Removed the dangling Ports the full-setup skill \02-app.ps1`` comment. There is no appropriate public URL to point at, so it was removed rather than inventing one.

3. Bring-your-own-app clarification (src/index.ts)

The config.clientId startup branch now clearly documents that this is the bring-your-own-app path — the caller has already pre-created an owning app (via --client-id / SPE_CLIENT_ID) and the server signs in as that app (no owning app is provisioned). A new startup line makes this explicit on stderr.

4. Restart-after-az login guidance (src/index.ts)

The bootstrap "not signed in" message now tells users to restart the MCP server after az login, because auth/session state is stamped at startup (a restart begins a fresh session and re-primes authentication).

5. New pure module + tests

src/onboarding-messages.ts houses the message builders (adminConsentUrl, adminConsentSection, byoAppStartupNote, azLoginNotSignedInMessage) so the copy is unit-tested in one place.

Test evidence

• npm run lint ✅ · npm run typecheck ✅ · npm run build ✅
• npm test ✅ — 713 passed | 3 skipped (baseline ~698 + 15 new tests).
• New/updated tests assert: the exact admin-consent URL (correct {tenantId} + client_id={appId}), the admin-vs-non-admin explanation, non-blocking wording, the missing-tenant fallback, no secret/token in the URL (only client_id), and that the vague skill reference is gone.

Guardrails

• No internal references; cites "PR Initial import: SharePoint Embedded MCP Server #3 review" only. MIT header on new files. No secrets in code/output. No tool names changed; app-gate/session logic untouched (messaging only). No auto-merge.