Create North Auth Provider for General FastMCP Usage

[JoshBragg-Cohere]

Design Document: https://www.notion.so/cohereai/MCP-North-Auth-Provider-3024398375db80398ce3e8e7ab828604

Changes:

• Updated dependencies
  • mcp -> fastmcp: changed dependency to ensure fastmcp imports were available (necessary for authprovider)
  • • asgi-lifespan: required for tests
  • • ruff: required for linting
• src/north_mcp_python_sdk/__init__.py
  • Changed NorthMCPServer to use FastMCP server as superclass
  • Updated initialization to use NorthTokenVerifier auth provider (this provider automatically applies middleware, so removed the manual middleware injection)
• src/north_mcp_python_sdk/auth.py
  • Fixed linting issues
  • Marked get_authenticated_user as deprecated (subject to change in design doc)
  • Implementation of get_authenticated_user now creates a user object from the access token
  • Removed AuthContextMiddleware (no longer required to attach user to context, instead use built in access token dependency injection)
  • Updated _parse_connector_tokens to use implementation from feat: FastMCPNorthMiddleware for easier FastMCP integration #29
  • _create_authenticated_user now creates a base AuthenticatedUser instead of custom AuthenticatedNorthUser
  • Marked server secrets and connector access tokens as deprecated (subject to change in design doc)
  • Implemented NorthTokenVerifier
    • Class implements FastMCP AuthProvider pattern
    • Provides necessary middleware with NorthAuthBackend used to handle key authentication
    • verify_token method is required to be defined from superclass, but in our implementation the auth backend does not call the token verifier function and instead implements this itself
• Updated unit tests to run on new codebase

[raphael-cohere]

What are these for? Why are we defining class variables here?

[JoshBragg-Cohere]

Added these to address the linter issues I was seeing. Type annotation for attribute '_server_secret' is required because this class is not decorated with '@final'

If we don't want to strictly define these types, we can look to remove it. I can also look to lessen my pyright strictness level.