Fix context init

[Gio-Tala]

P1B: Starter Task: Refactoring PR

Use this pull request template to briefly answer the questions below in one to two sentences each.
Feel free to delete this text at the top after filling out the template.

1. Issue

Link to the associated GitHub issue:
#115

Full path to the refactored file:
packages/ui/src/theme/context.tsx

What do you think this file does?
(Your answer does not have to be 100% correct; give a reasonable, evidence‑based guess.)
This file manages UI theme info for opencode, e.g. which color theme is active, lightmode vs darkmode, etc. It basically controls how we load, apply, and persist these themes throughout a user's session.

What is the scope of your refactoring within that file?
(Name specific functions/blocks/regions touched.)
I refactored the init parameter's function in the call to createSimpleContext. The init function had a lot of children functions that I just extracted into the top level of the file. This way, our init function only had to call these functions instead of creating and then calling all of them inside itself.

Which Qlty‑reported issue did you address?
(Name the rule/metric and include the BEFORE value; e.g., “Cognitive Complexity 18 in render()”.)
Function with high complexity (count = 135)

2. Refactoring

How did the specific issue you chose impact the codebase’s maintainability?
This issue made the file very unreadable. In fact, when I first found the line corresponding to this function, which I was already explicitly looking for after reading the Qlty report, I wondered at first glance where the function was. That was before I realized, this function init that was supposed to be nothing more than a parameter for an arg to another function was literally the entire rest of the file! Imagine if I wasn't looking for this function in particular but was just reading the file as a whole to refactor it - I'd have no idea what I was looking at. Plus, if we ever did want to refactor the actual logic behind this function, changing it would be a mess as it was a whole monolothic structure that included in a very messy way most of the the functions it called.

What changes did you make to resolve the issue?
Essentially just extracting some children function from a lengthy function passed into parameter init. So basically instead of defining and calling functions in init, we only have to call functions, since they're now defined at the top level.

How do your changes improve maintainability? Did you consider alternatives?
Now that we separated the children functions out, the code behind the init function is a LOT more readable, as it's about an order of magnitude shorter. By making the code more readable and isolating these children function, if we ever decide to change the actual logic of the init function (e.g., such that it doesn't take a particular prop and call one of the child functions anymore) then this wll be a lot easier as we only have to manipulate the corresponding call to the child function. There's also a chance we may want to use any of these functions somewhere else, in which case having them separated out allows us to call them elsewhere in the same file or export to other files, instead of having to create duplicate code.

3. Validation

How did you validate that the change is correct?
I made tests for the extracted functions to make sure they still performed as originally intended.

Attach a screenshot of the test coverage showing the lines were executed by the tests.
(62.50 = % functions covered, 51.56 = % lines covered. Note, none of this file had any test coverage before, so all test coverage relates to my changes only).

Attach a screenshot showing the tests that cover the change passing during CI

Attach a screenshot of qlty smells --no-snippets <full/path/to/file.ts> showing fewer reported issues after the changes.
Before:

After: