productivity:ms365: OAuth fails with AADSTS900971 (No reply address provided) after sign-in

## Summary

Connecting the `productivity:ms365` plugin via Claude Code's `/mcp` command consistently fails Microsoft sign-in with `AADSTS900971: No reply address provided`. The error appears *after* credentials are accepted, not at the initial `/authorize` step — which is diagnostic of a server-side app-registration misconfiguration rather than a malformed request.

**Plugin:** `productivity:ms365` (hosted MCP at `microsoft365.mcp.claude.com`)

## Reproduction

1. Run `/mcp` in Claude Code and start the OAuth flow for `productivity:ms365`.
2. Open the authorize URL returned by the plugin in a fresh browser session (private/incognito window, no prior MS session).
3. Sign in with a valid Microsoft work account.
4. Microsoft displays:
> Sorry, but we're having trouble signing you in.
>
> AADSTS900971: No reply address provided.
5. The browser never reaches the `http://localhost:/callback` redirect.

## Evidence the request is well-formed

The `/authorize` URL emitted by the plugin contains a well-formed `redirect_uri` query parameter:

```
redirect_uri=http%3A%2F%2Flocalhost%3A50902%2Fcallback
```

Other observed parameters in the request:

| Param | Value |
|---|---|
| `client_id` | `08ad6f98-a4f8-4635-bb8d-f1a3044760f0` |
| `response_type` | `code` |
| `code_challenge_method` | `S256` (PKCE — public-client flow) |
| `scope` | `api://07c030f6-5743-41b7-ba00-0a6e85f37c17/.default offline_access openid email` |
| `prompt` | `consent` |

## Why this points server-side, not request-side

- The flow advances through `/common/oauth2/v2.0/authorize` → `/common/SAS/ProcessAuth` → error. If `redirect_uri` were truly missing from the request, AAD would error at `/authorize` rather than after credential entry.
- Reproduces in a clean incognito window with no prior SSO state — rules out stale-cookie / SSO-chain causes.
- Reproduces across multiple retries with fresh authorize URLs.

## Likely root cause

The Azure AD app registration `08ad6f98-a4f8-4635-bb8d-f1a3044760f0` appears to have its `http://localhost/...` reply URL listed under the wrong platform type (probably **Web**), while the OAuth request is being made as a public client (PKCE, no secret). AAD won't match a Web-platform reply URL against a public-client request, and reports the failure as "no reply address provided."

## Suggested fix

On the app registration `08ad6f98-a4f8-4635-bb8d-f1a3044760f0`, under **Authentication**:

- Add a platform of type **Mobile and desktop applications** and register `http://localhost` (AAD wildcards the port for `http://localhost` under that platform type for public clients), **or**
- Mark the existing platform as a public client / allow public-client flows, depending on the intended trust model.

`AADSTS900971` is documented as raised when the app registration has no reply URL configured for the inferred client type, even when one is present in the request.

## Related

- #24 — a separate but adjacent bug in `legal:ms365` (duplicate `prompt` parameter). Different symptom, different error, but suggests the M365 plugin family's OAuth URL construction / app-reg setup may benefit from a once-over.