internal/observability: derive metricProcedure from transport, not encoding

[elliotchance]

Problem

metricProcedure (added in #2359) is emitted on logs so an M3 alert can be
mapped back to the matching logs — its value is meant to equal the M3
procedure tag. It was derived from the encoding, but the M3 tag is shaped
by the transport, so the two diverge when a proto service is called over
HTTP:

Transport	M3 procedure tag	logged metricProcedure (before)	match
gRPC	uownservice/searchassets	uownservice/searchassets	✅
HTTP	uber.infra.uown.uownservice--searchassets	uownservice/searchassets	❌

As a result, availability alerts on HTTP-invoked endpoints linked to log
queries that returned no results, making them hard to debug.

Fix

Derive metricProcedure from req.Transport instead of the encoding:

• gRPC → short, slash-delimited form with the package path dropped
  (uownservice/searchassets)
• every other transport (HTTP, TChannel) → fully-qualified name,
  lowercased, with :: → -- (uber.infra.uown.uownservice--searchassets)

The M3 procedure tag itself is unchanged; only the log field is corrected to
match it. Encoding is still used to skip raw/unknown encodings.

Test plan

• Updated TestMiddlewareLoggingWithMetricProcedure to be transport-aware,
  including the gRPC-vs-HTTP regression pair described above.
• go test ./internal/observability/... passes; gofmt and go build clean.

🤖 Generated with Claude Code

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}