feat(server): optional multi-profile runtime with explicit request routing

Hi, and thank you again for the clear and responsive handling of #1836, #180, and #116. Those fixes and discussions have been very helpful in my workflows.

Use Case

I have two local Python applications that need to use the same set of already-authenticated NotebookLM profiles/accounts concurrently.

Each NotebookLM account has its own account-level daily usage limits, so there is a practical reason to operate multiple accounts. At the same time, having two independent application clients consume the same account's master-token auth can cause them to re-mint credentials independently and invalidate each other's session.

I reviewed the experimental REST server in v0.8.0a4. My understanding is that it intentionally binds one profile and one NotebookLMClient for the process, while the Python API already documents the single-process multi-tenant pattern of using one long-lived client per tenant:

https://github.com/teng-lin/notebooklm-py/blob/v0.8.0a4/docs/python-api.md#single-process-multi-tenant-guidance

Target Surface

• CLI
• Python API
• MCP
• REST server
• Desktop extension
• Documentation

Question / Proposed Direction

Would you consider an optional multi-profile mode for notebooklm-server?

The intended shape would be:

• load multiple already-provisioned named profiles;
• keep one long-lived NotebookLMClient per distinct profile/account;
• require each request to select its target profile explicitly;
• preserve the current single-profile behavior as the default.

This is only a question about whether that direction fits the intended scope of the experimental REST server. If it does, I would also appreciate your preference for how profiles should be configured and selected by requests before anyone proposes an implementation.

Non-Goals

This request is not asking for:

• browser login or account provisioning inside the server;
• sharing one client across accounts;
• automatic account rotation or quota balancing;
• public multi-tenant hosting, tenant signup, or RBAC.

Alternative

The current alternative is one notebooklm-server process per account, shared by both applications. That should preserve one auth consumer per account, but it requires a separate port, token, health check, configuration, and supervisor unit for every account.

If this is outside the intended server scope, that is completely understandable—we can implement and maintain the extra orchestration on our side. I wanted to ask first because the underlying one-client-per-tenant model already appears to be supported by the library.