[DOCS-03] Publish telemetry, location, event, webhook, and usage guides #4

@jaavid

Background

CoreLink is managed as one product across multiple implementation repositories. This work is the executable feature owned by developer-docs under EPIC-04.

Problem

The telemetry/location/event/webhook/usage documentation depends on several contract slices, but the backlog previously modeled this only as API-02 through API-04 and left downstream outcomes unresolved.

Goal

Publish versioned telemetry, location, event, webhook and usage guides that are runnable against supported contract revisions and accurately reflect accepted product maturity.

Parent

• Primary Product Epic: EPIC-04
• Backlog ID: DOCS-03

Scope

• Publish supported telemetry/location ingestion and query journeys.
• Publish event/webhook delivery, retry/replay and failure semantics.
• Publish usage/reconciliation behavior required by supported developer journeys.
• Reconcile examples and claims with accepted API revisions and maturity state.
• Retain documentation validation evidence suitable for Partner Platform/Beta gates.

Out of Scope

• Publishing draft or internal behavior as a stable supported API.
• Treating documentation CI alone as Product Acceptance.
• Creating a separate repository roadmap.

Acceptance Criteria

• Each guide identifies the exact supported API/tool version or maturity state it targets.
• Telemetry/location examples are runnable and align with accepted canonical semantics.
• Event/webhook guides document signatures, retries, replay/failure behavior and relevant security boundaries.
• Usage guides align with accepted usage/reconciliation semantics and do not overstate billing maturity.
• Links, examples and version claims pass documentation validation.
• Retained evidence is linked and EPIC-04/EPIC-05 documentation exit criteria are measurably advanced.

Dependencies and acceptance state

• Active contract prerequisites: API-02 telemetry/location contracts, API-03 partner/event/webhook contracts, and API-04 schema/event contracts must provide version-identifiable supported slices before corresponding guides are promoted as supported.
• Execution may proceed incrementally: guide structure and clearly marked draft/scaffold content may advance before all contract slices are Product Accepted, provided maturity is explicit.
• Blocks: Partner Platform developer documentation acceptance, downstream runnable examples, DOCS-05 documentation-quality validation, and release-readiness claims that depend on these guides.
• Current dependency state: See the CoreLink Product organization Project.

Planning Metadata

• Type: Feature
• Priority snapshot: P0
• Product milestone snapshot: Partner Platform
• Domain snapshots: docs, telemetry
• Area snapshot: documentation
• Complexity: L
• Created in status: Triage
• Current status and DRI: See the CoreLink Product organization Project.
• Intended repository labels: type:feature

Definition of Done

• Acceptance criteria demonstrated.
• Supported claims map to accepted/version-identifiable contract slices.
• Required documentation checks pass on the accepted revision.
• Security/tenant-sensitive behavior is reviewed.
• Examples are runnable or explicitly classified as draft/scaffold.
• Documentation/release maturity notes are reconciled.
• Pull request(s) and retained evidence are linked.