Separate read and edit views for memories and tasks #103

Problem

Opening a task or memory currently exposes editable fields and raw Markdown even when the user only wants to read it.

Expected behavior

• Existing item links open a readable detail view with rendered Markdown and metadata.
• An explicit Edit action opens the editor for authorized writers. Read-only users can view content without edit controls; server authorization remains authoritative.
• New task/memory stays a creation form. Save returns to the read view; Cancel returns without persisting changes.
• Retain number, status, assignment, subtasks, revision history, moderation and future related-item sections in the appropriate views.

Navigation and layout

Use canonical routes from #73/#82 and document any edit route or mode. Preserve legacy URLs, project/personal context, back links and showClosed filters. Links copied/shared should target the read view. Existing sessions with editor URLs must not lose unsaved changes. Keep compact headings and normal-weight subtask titles; do not add redundant pills.

Dependencies and ownership

Coordinate with #74, #84 and #85: those tasks own Markdown renderer and Write/Preview inside editors; #103 owns read-first navigation and view/edit separation. Use the same renderer and services rather than duplicate editors. Coordinate with in-progress #73 before choosing routes.

Acceptance

• Clicking an existing task/memory displays content, not textareas or Markdown source.
• Edit is explicit and available only to authorized writers.
• Save/Cancel/browser history preserve the expected item and context.
• External updates refresh read views; dirty editors retain changes and detect stale saves.
• Direct URLs, narrow screens, keyboard access, revisions and permission changes verified.

Agent handoff

Planning only in this session. Read subtasks and current code before implementing; coordinate overlapping Markdown/route work.