Use MSA accounts in a different app registration in development mode.

[payneio]

This pull request updates authentication to use Microsoft Entra ID tokens (idTokens) instead of accessTokens for both client and server, ensuring compatibility with consumer accounts and improving token validation logic. It also updates the registered application client ID and authority settings to match the new configuration.

After this change, the default dev environment authentication is to the consumer/MSA endpoint with a consumer app registration. This hardens the security on our default app registration (which will be deleted).

Authentication and Token Handling Updates:

• All API requests now use the idToken (JWT format) for authentication instead of the accessToken, which resolves issues with token formats for Microsoft consumer accounts. (workbench-app/src/libs/useWorkbenchEventSource.ts, workbench-app/src/libs/useWorkbenchService.ts, workbench-app/src/services/workbench/workbench.ts) [1] [2] [3] [4] [5] [6]
• Server-side token validation logic now correctly handles both Entra ID and Microsoft Account tokens by supporting multiple claims (appid, aud, azp) and user identification via either tid.oid or sub. (workbench-service/semantic_workbench_service/middleware.py) [1] [2]

Configuration Changes:

• Updated the client ID and authority in both the example environment file and code to use the new Semantic Workbench Consumer app registration and point to the consumer authority. (workbench-app/.env.example, workbench-app/src/Constants.ts, workbench-service/semantic_workbench_service/config.py) [1] [2] [3] [4]

Code Quality Improvements:

• Improved type imports for Awaitable and Callable to use collections.abc for better compatibility and clarity. (workbench-service/semantic_workbench_service/middleware.py)