Add project descriptions and discussion notes to the Projects API and UI #60

Context

The Stress testing Ox Alpha project needs durable project-level context: why the project exists, current operating assumptions, triage decisions, and notes that apply across several issues. Today a project stores only a title, owner, state, number, and repository. Operators must repeat project context in every issue, and there is no project timeline for decisions such as changing provider order or pausing a stress lane.

Outcome

Add a project description and a durable discussion or activity-note surface to the Projects API, CLI workflow, and web UI. Keep issue comments attached to issues; use project notes only for project-wide context and decisions.

API shape

• Add description or body to project create, get, list, and update responses. Choose one canonical field and document its Markdown behavior.
• Add authenticated project update support for title, description, and state.
• Add project note list and create endpoints with stable IDs, author, timestamps, and Markdown body.
• Define edit and delete authority explicitly. Preserve an immutable activity record for state changes even if editable discussion notes are supported.
• Return paginated notes and avoid embedding an unbounded timeline in the project object.
• Keep repository membership as the project authority boundary.

Web and live behavior

• Show the project description above the board without crowding the issue columns.
• Add a project activity or discussion section with useful empty, loading, degraded, and unauthorized states.
• Subscribe project boards to project PubSub updates and re-read through the viewer's authorization boundary so remote CLI changes appear without a reload. The workspace list already subscribes; the individual project board currently does not.
• Render cross-repository issue identities without leaking private source metadata.

CLI and documentation

• Document generic openagents api examples for updating a project and listing or creating notes.
• Add named CLI commands only after the API contract stabilizes.
• Update the Issues and Projects assessment with the deliberate differences from GitHub Projects V2 and the longer-term Linear-compatible direction.

Acceptance criteria

• An authorized operator can add and update a Markdown project description through the API.
• An authorized operator can create and list project notes through the API.
• An unauthorized reader cannot infer private project or note data.
• An open project board updates after a CLI project or project-item mutation without a manual reload.
• The web UI exposes the description and paginated discussion/activity surface accessibly.
• API, authorization, migration, serialization, LiveView, and PubSub tests pass.
• mix precommit passes.