docs: define installed server deployment and discovery

[pcvantol]

Summary

• Canonicalizes the product's installed headless-server target, central product-owned storage, versioned HTTP boundary, stable identity, and launchd lifecycle.
• Defines discovery as candidate-only and pairing/binding as authenticated, explicit, and pinned; no direct cross-product SQL or silent rebinding.
• Updates the owning roadmap/DAG sequencing: Forge→EP→Forge minimum seams remain independent of full Workspace UI and universal-installer productization.

Validation

• Documentation-only change; repository validation completed locally.

[pcvantol]

Cross-repository architecture reconciliation — server deployment/discovery design. This is an automated review note, not implementation or installed qualification evidence.

The corresponding proposals now exist:

• Forge: docs: define installed server deployment and discovery forge#47 @ 1060b5e2002c2e945e96a887b884f566c40519b2
• EP: docs: define installed server deployment and discovery engineering-platform#101 @ 4deb6717e85be2eda078ba8273d3d7921e414a6d
• Workspace: docs: define installed server deployment and discovery workspace#13 @ 77c579d8412f2459d647023dcfb6d4c866332866
• Forge Platform: this PR @ 6ca7748

They cover independent headless product servers, SQL/files outside Git, versioned HTTP, launchd, stable instance identity, candidate-only discovery, authenticated product-owned binding, Workspace Server/Client separation, installer composition, and minimum-autonomy vs later-productization sequencing. These are PENDING_PR until owning merges; their 'canonical target' labels are not proof of merge or implementation. Publish/merge the shared contract before consumers rely on its main URL, subject to real checks and existing authority.

Remaining reconciliation checks before declaring the four-repository documentation closure complete:

1. Update conflicting 'network discovery protocol remains open' wording in the existing architecture/MVP text to reference ADR-0006 for the decided part, while leaving concrete protocol/security implementation qualification explicit.
2. Align Forge's machine-readable implementation DAG with the new source/DoD for F1/F2/server storage and lifecycle; changing only Markdown must not leave machine consumers interpreting a different dependency graph. Preserve full-product milestones without imposing Workspace/full installer completion on the bounded first loop.
3. Distinguish a session-bound LaunchAgent from a system-service profile: headless is not proof of operation across logout/reboot. Each product owns its service account, credential availability and lifecycle qualification; do not mutate current services as part of this documentation change.
4. Make the installer target cover selection of any one/two/three server roles with existing remote peers, partial/offline configurations and no cyclic startup requirement. Discovery/candidate availability must never silently substitute a different trusted instance. Capability-unavailable is not necessarily process-unhealthy.

Do not create duplicate architecture branches or touch the concurrent Forge #46 / EP assurance implementation lanes. Each product keeps its own authority and store; the installer never writes those databases.