refactor: repo folder structure (#1038)

* refactor(repo): move OpenWork apps into apps and ee layout

Rebase the monorepo layout migration onto the latest dev changes so the moved app, desktop, share, and cloud surfaces keep working from their new paths. Carry the latest deeplink, token persistence, build, Vercel, and docs updates forward to avoid stale references and broken deploy tooling.

* chore(repo): drop generated desktop artifacts

Ignore the moved Tauri target and sidecar paths so local cargo checks do not pollute the branch. Remove the accidentally committed outputs from the repo while keeping the layout migration intact.

* fix(release): drop built server cli artifact

Stop tracking the locally built apps/server/cli binary so generated server outputs do not leak into commits. Also update the release workflow to check the published scoped package name for @openwork/server before deciding whether npm publish is needed.

* fix(workspace): add stable CLI bin wrappers

Point the server and router package bins at committed wrapper scripts so workspace installs can create shims before dist outputs exist. Keep the wrappers compatible with built binaries and source checkouts to avoid Vercel install warnings without changing runtime behavior.

apps/app/pr/OpenCode Server.md

@@ -0,0 +1,56 @@
+# OpenCode Server
+Run tasks from a shared runtime
+---
+## Summarize
+- Define a local OpenCode server that OpenWork can discover, connect to, and use for task execution across devices
+---
+## Define problem
+- OpenWork needs a reliable way to run tasks without bundling a full CLI per device while keeping setup simple and transparent
+---
+## Set goals
+- Enable a host machine to run tasks for multiple OpenWork clients with clear status, fast connect, and predictable behavior
+- Keep setup minimal and align with least-privilege, mobile-first usage
+---
+## Exclude scope
+- Building a hosted SaaS, multi-tenant cloud, or marketplace for remote agents
+- Supporting non-OpenWork clients beyond a basic compatibility layer
+---
+## Describe personas
+- Mobile user who wants to run tasks from a phone against a home or work machine
+- Power user who wants a stable local runtime for repeated workflows
+- Admin who needs simple setup and clear permission prompts
+---
+## Define requirements
+- Functional: discover host on LAN, connect via pairing, run tasks, stream logs, and handle reconnects gracefully
+- UX: show connection status, explain permissions, and expose a clear health panel with actionable errors
+---
+## Detail integration
+- Lifecycle: start server on host, advertise via local discovery, accept pairing, and serve OpenCode APIs over a secured channel
+- Host/client: host runs OpenCode runtime and permission gates while clients send tasks, receive progress, and read logs
+---
+## Set permissions
+- Require explicit pairing approval, scoped runtime permissions, and per-task confirmation for sensitive tools
+---
+## Cover telemetry
+- Optional local metrics for uptime, connection failures, and task success, stored on host and never uploaded by default
+---
+## Map flow
+- Onboarding: guide install, start server, and generate pairing code
+- Connect: discover host, enter code, and validate permissions summary
+- Health: show server uptime, last task status, and recovery actions
+---
+## Note risks
+- Network discovery inconsistencies across platforms and routers
+- Trust confusion if pairing and permission prompts are unclear
+---
+## Ask questions
+- Should remote access beyond LAN be supported in this phase, and if so, which transport is acceptable
+---
+## Measure success
+- 90%+ successful first-time pairing on supported platforms with fewer than two manual retries
+- Stable task execution with <1% disconnect-related failures over 7 days
+---
+## Plan rollout
+- Phase 1: local discovery and pairing on desktop host with basic status UI
+- Phase 2: mobile client support, health panel, and reconnect logic
+- Phase 3: permission refinements, metrics, and troubleshooting guide