Refactor wordmark many returns

[sanikaj4]

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: #40

Full path to the refactored file: packages/tui/src/util/presentation.ts

What do you think this file does?
(Your answer does not have to be 100% correct; give a reasonable, evidence‑based guess.)
I think this file builds an "OpenCode" wordmark/logo and a session epilogue message shown at the end of a session, including the session title and a command to continue the session.

What is the scope of your refactoring within that file?
(Name specific functions/blocks/regions touched.)
The refactor is scoped to the draw helper function nested inside the wordmark function (lines ~10-15 of the original file). I did not make edits to wordmark's outer logic or the sessionEpilogue function.

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 many returns (count = 6) on wordmark, reported at packages/tui/src/util/presentation.ts:10.

2. Refactoring

How did the specific issue you chose impact the codebase’s maintainability?
The draw closure branched on each character with a chain of if (...) return, so every new special character or format rule required adding another return branch. This made the function harder to scan and thus increased the chance of an inconsistent/missed case as it grew.

What changes did you make to resolve the issue?
I replaced the if/return chain with a Record<string, string> lookup table (chars) mapping each special character (_, ^, ~, " ") to a pre-formatted output string. A single return chars[char] ?? fallback handled both matched characters and the default case.

How do your changes improve maintainability? Did you consider alternatives?
The function now has one return statement instead of six, and adding a new special character means adding one key to the table rather than another branch. I considered a module-level lookup of formatter functions keyed by character (so fg/shadow/bg could be threaded in), but I realized it required every entry to accept parameters most of them ignored. It would be simpler to build the string values directly inside draw, where fg/shadow/bg are already in scope.

3. Validation

How did you validate that the change is correct?
To validate the changes is correct, I ran qlty smells packages/tui/src/util/presentation.ts before and after (before: Function with many returns (count = 6), and after: no smells reported), ran bun test to confirm the existing test passes, and generated a coverage report showing 100% line and function coverage on the file.

Attach a screenshot of the test coverage showing the lines were executed by the tests.

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.