attribute: panic in places that should be unreachable

[pellared]

This would be a bug in the code and would encourage filling bugs in this repo.
But, I will revert it and consider creating a separate PR for it.

Originally posted by @pellared in #8038 (comment)

[lavish-gambhir]

I can work on this one! Looks like hashValue's default is the only panic left after #8038 cleaned up String/Emit/AsInterface.
I'd just drop the panic and return the hash as-is — it's unreachable through the public API anyway. Could hash a sentinel ID instead if you'd rather keep unknown types hashing distinctly. What do you think?

[chrikrah]

The reading @lavish-gambhir posted holds on 26d897d: attribute/hash.go:289 is the only panic( left in
attribute/*.go outside tests, and nothing reaches it. The zero attribute.Value carries type EMPTY,
which hashValue handles at hash.go:283, and vtype is unexported.

Two threads elsewhere already refused both variants of dropping it:

• attribute: investigate and fix unexpected panic in unreachable code paths #8062 tried it and @pellared requested changes: "This is the opposite of what the issue is about".
• Fix/hashvalue unknown type panic #8723 hashed an unknownID instead, and @MrAlias closed it unmerged on 2026-08-11. He gave the reason: vtype
  is private, so reaching the branch means an internal bug, most likely a Type added without its hashing
  implementation. A sentinel hides that, and gives different values of the missed type the same Distinct,
  which can silently combine metric streams.

So the June question has an answer, and it arrived in August in another thread.

That leaves this issue's own subject: which unreachable defaults should gain a panic. Two in sdk/metric
have one already, and that criterion does not cover them, because a caller supplies the input:

metric.DefaultAggregationSelector(metric.InstrumentKind(99))   // panic: unknown instrument kind
exemplar.NewHistogramReservoir([]float64{0, 10}).
    Offer(ctx, time.Now(), exemplar.Value{}, nil)              // panic: unknown value type

Both run from a plain main, no internal package. reader_test.go:291 pins the first: it asserts
assert.Panics on the zero InstrumentKind. And exemplar.Value{} documents its own type as "should
not be used".

Are those in scope here, or is this issue about attribute only?