feat: move diff_style from config to kv.json and add toggle menu items in command_list

[ariane-emory]

What does this PR do?

• Remove diff_style from TUI config schema
• Update diff rendering to read from kv.json instead of config
• Change 'stacked' value to 'unified' for consistency
• Add System menu item to toggle between auto and unified diff styles
• Menu items immediately update diffs when toggled

This improves the UX by allowing the diff style to be toggled dynamically while OpenCode is running and improves consistency relative to other similar options already in Opencode. Since the TUI group in the configuration file is not validated strictly, this will not be a breaking change for any existing configurations.

When diff_style is unified, option to switch to automatic diff_style is offered:

When diff_style is auto, option to switch to unified diff_style is offered:

Resolves #10711

How did you verify your code works?

Manual testing, bun typecheck, bun test.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

No duplicate PRs found

[IdrisGit]

I think moving it to KV makes more sense, since we already have similar commands in the TUI, it also helps with improving the visibility of the feature, much easier for users to find this setting in command palette rather than the config file.

And as this is a visual feature that can be easily toggled, I don't think anyone is going to complaint about it not being in the config anymore.

[rekram1-node]

Can we just keep it in config and use kv, I'd prefer not to break configs if we can help it

[ariane-emory]

@rekram1-node I'm slightly confused - why would it need to be both in config and KV at the same time? The change would not break any existing configs since the tui property's contents is not validated strictly: the config property would just become vestigial, tolerated but not effective.

Happy to take it down whichever route you'd prefer, just need a little clarification on what it would mean to both have the config property and to use KV at the same time, it seems to me that this'd be a one or the other situation, but perhaps I am overlooking something.

[rekram1-node]

if someone has a field in their config, and next time they start the app, it isn't respecting that field, and there is no clear indication as to why, then that appears as a bug to them

[ariane-emory]

@rekram1-node Fair enough. I'm still uncertain as to what was meant by "keep it in config and use kv," - what does the "and" here imply? I'm not clear on what using both would look like.

Would the config's state be the initial state at startup, but it could then be toggled temporarily using the value in KV, something like that?

Just trying to be sure of the correct interpretation of what you'd said.

[IdrisGit]

yeah I think it's fair enough to consider if someone already have it added in their config, due to sheer number of users OC have this can mean alot of users.

Here are my suggestions:

1. If user have the value defined in config, override it over the kv value and disable the command in the palette or persist the toggle for the session only and reset when OC restarts.
2. If user have config value defined, show a toast that it is deprecated and will be moved from the config, and later after a few weeks remove it from config.

[ariane-emory]

@IdrisGit Both of those sound like they could be fair options to me. But of course, @rekram1-node is the boss here and I'm happy to take it down whichever path he'd prefer.