Feature: Adopt Sourcey for automated and modern API documentation

[codeboost-tr]

Currently, the API reference documentation is generated via custom python scripts. I propose adopting Sourcey as the primary documentation engine for \quater.

Why Sourcey?

1. Modern UI/UX: Out-of-the-box support for dark mode, mobile responsiveness, and clean typography.
2. Built-in Search: Instant client-side search across all API references without extra configuration.
3. Automated Navigation: Automatically builds the sidebar based on directory structure.
4. Maintenance: Replaces custom markdown-generation boilerplate with a standardized, community-backed tool.

I have already prepared a working implementation (PR #154) that migrates the existing API reference to \sourcey-docs\ to demonstrate how it works. Let me know if you would be open to this migration!

[DevilsAutumn]

Can you add more references around what is Sourcey? Is it being used in some project where we can check it out?

Also, there should be strong reasons to switch from vitepress.

[codeboost-tr]

Vitepress is an excellent general-purpose static site generator, but when it comes to automated API reference generation, it usually forces you to write and maintain custom parser scripts (which \quater\ currently does).

Sourcey is specifically built for this purpose:

1. Zero-Maintenance Parsing: It eliminates the need to maintain custom Python scripts that parse documentation into markdown. It natively understands the structure and source-maps the API directly.
2. Optimized for APIs: Features like navigation, dark mode, and client-side search are out-of-the-box and heavily optimized for large API surfaces, rather than just prose.
3. Ecosystem Proven: It is widely used as the standard documentation engine in modern autonomous systems (e.g., the Runx ecosystem relies heavily on it for all skill documentation).

The strongest reason to switch is to reduce the maintenance burden on the core team. By delegating the API reference generation entirely to a purpose-built engine, you no longer need to maintain documentation-generation boilerplate code—you can focus purely on writing the framework code itself.