[Observability] Audit cross-signal fields, error semantics and compatibility boundaries

## Parent and scope

Parent roadmap: #3562, Workstream 1.

Extract the current-state audit from the [ownership scope recorded in #3562](https://github.com/apache/dubbo-go/issues/3562#issuecomment-5131193627) into an independently deliverable documentation task.

The [2026-09-05 weekly report](https://github.com/apache/dubbo-go/discussions/3719) still tracks observability as an umbrella activity. As of 2026-09-07, no separate public claim or open PR was found for this specific audit deliverable. This issue is initially unassigned; existing implementation ownership remains in place.

## Deliverables

- [ ] Add a source-backed inventory of the current Metrics, Trace, Log and Metadata representations of service, method, protocol, side and error information. Record the actual key names and value sources; explicitly mark fields that are absent or not applicable.
- [ ] For each mapping, include the implementation location, signal-specific meaning, and relevant existing tests. Pin the audited revision and distinguish merged behavior from open PR proposals.
- [ ] Document low-cardinality metric dimensions versus high-cardinality diagnostic data, including trace/span IDs and free-form error text. Identify inconsistencies without changing exported behavior.
- [ ] List compatibility constraints for existing metric names/labels, trace attributes, configuration and logger behavior.
- [ ] Produce a compact follow-up matrix: observed gap, affected files, related issue/PR, existing owner where publicly recorded, and a concrete validation scenario.

## Acceptance criteria

The documentation must be reviewable against a named repository revision. Every statement about existing behavior must have a code or test reference. Proposed semantics must be clearly separated from observed behavior; unresolved mappings remain explicit questions.

Use the current target branch at implementation time. The triage baseline is `develop@5f54b6a8cc9702abb320aa324784176689878ed0` (2026-09-06). A reviewer should be able to select a field/error scenario and trace its current representation across the applicable signals.

## Boundaries

Documentation only. Do not rename metrics, change label cardinality, implement a shared error-classification package, alter span lifecycle/propagation, or build dashboards.

Metrics implementation remains under #3337; tracing under #3338 / #3551; metadata under #3356 / #3499; default filter wiring and related protocol integration under #3568. Record overlaps for coordination rather than taking over those changes.