docs(360): project-oriented editing and extensions feasibility study

[Eswar0108]

Fixes nothing code-wise; contributes to #360 (exploration deliverable).

What

Adds docs/ProjectExtensionsFeasibilityStudy.md — the exploration/architecture study requested by #360, in the same style as the existing docs/AIWorkPanelFeasibilityStudy.md. Docs-only, zero code/config/dependency changes.

Coverage — all seven suggested acceptance outputs

#360 acceptance output	Section
Which project-oriented features belong in core	§4.1 (built-in list + decision rule)
Proposed architecture for integrations/extensions	§5.1 (layered diagram)
How extensions expose capabilities to the Work panel	§5.2–§5.3 (manifest → registry → proposal contract)
Permissions/security model for tools that read/modify project content	§6 (capability grants, threat model, deny-by-default)
Discover / install / enable / disable / configure lifecycle	§7 (v1 deliberately minimal: folder-drop, no marketplace)
Which features stay built-in rather than extensions	§4.1 + §4.3 (explicit out-of-scope)
One small proof-of-concept if practical	§8 (Local Model Bridge sketch + exit criteria)

Grounded in the actual codebase

Every factual claim was verified against current sources before writing:

• POST /api/ai/work single-document contract + stale-result guard + undoable apply (backend/routers/ai.py, frontend/src/hooks/useAIActions.ts)
• The project-level primitives already exist: find_note_files() + SQLite FTS5 indexing in backend/knowledge_logic.py
• Key security finding: backend/routers/files.py serves absolute-path read/write with no sandbox — acceptable for user-initiated calls today, but must gain project clamping + review mediation the moment a model or extension can drive it (§6.3)
• Provider stack, secure key storage, and settings persistence as the reuse surface (§5–§7)
• AIPanel tab shell (chat / work / translate / settings) as the capability renderer

Sequencing (per the issue's Important Considerations)

The study is explicitly gated behind #357 (project-wide AI workflows, currently assigned to @petertzy): §10 recommends no extension code be merged until #357 ships, a project-root concept exists, and one concrete third-party need is identified. Until then this document is the deliverable.

Verification

• All 7 referenced files and 10 referenced symbols/endpoints grepped against the repo before submission
• Structure mirrors the accepted AIWorkPanelFeasibilityStudy.md precedent (header block, numbered sections, tables, verdict)
• Docs-only → no CI risk; Frontend/Backend checks untouched