Add user metadata to conversation messages

Currently, a conversation consists of "user" and "assistant" messages. This works fine in a single-player context, but when sharing your conversations across a team of people, multiple people can participate in the same conversation. For contextual purposes, it makes sense to tag user messages with the appropriate user name.

There are a few ways to get this information, and all of this should of course be configurable (not in the least for privacy purposes):

• Detect git config user.name and git config user.email and use those.

• We can also load this information from a local-only configuration file for JP. We already have local configuration files, however, they are only loaded if inherit = true (default) in the workspace configuration file. However, I can also envision projects not wanting to load any non-workspace settings, so they set inherit = false, but you'd still want to be able to configure certain user-specific properties such as user.name regardless of whether other properties are inherited or not. I'll have to give this some more thought what the best composable solution is here.

• Environment variables are another way to get this information (e.g. JP_USER=Jean). This is also already supported similar to local configuration files, and these will be loaded (since there's (currently) no such thing as a local vs workspace environment variable). But I still think a proper file-config-based solution is merited.

Also, aside from adding user names as context to user-generated messages, we might optionally add LLM model context to assistant messages. E.g. # Assistant becomes # Assistant (google/gemini-2.5-pro). This is relevant, because models can be changed mid-conversation, although it's not as important as identifying users, so we might skip this for now.

No files, tests, or entry points are named. Start by locating conversation message handling and the existing workspace, local configuration, and environment-variable loading; then determine how user metadata should be selected and represented, with configurable privacy behavior and optional model context as the definition of done.