Consider removing `commons_server()` from API

[cpsievert]

And using shinychat::chat_server() instead.

Currently, commons_server() does 3 things:

1. Creates a commons_server_start span.
   • Could be removed considering that Shiny already has instrumentation for the session's lifecycle?
2. Creates a conversation id.
   • This is a hack (that I added) and can go away when we have Public conversation ID, emitted on OTel spans as gen_ai.conversation.id shinychat#343
3. "Pre-warms" the client (i.e., builds the index, etc).
   • We might want to revisit how this works, but regardless, it might be better if this was explicit rather than implicit. Essentially the (recommended) API would change from:

client <- ...
commons_server("chat", client)

to

client <- ...
client$prewarm()
chat_server("chat", client)

I'm not sure if it's possible today, but at least at some point it should be possible to prewarm/cache the index independently of the shiny runtime. In that case, you might not want the pre-warming at all (i.e., you only update the index as the knowledge base gets updated).

[cpsievert]

For more context, a motivator for this change is for things like querychat which calls shinychat::chat_server(). If commons has it's own commons_server(), it's harder to imagine how querychat would support a commons layer. Obviously, there are other compatibility concerns we'd have to address to make that happen, but I also think it helps commons position itself conceptually in the landscape if it's essentially just an ellmer agent.