Bug: All telemetry attributes exported as strings instead of correct OTel types

Summary

Attributes.prepare() in src/main/java/dev/openfga/sdk/telemetry/Attributes.java:130 uses AttributeKey.stringKey() for every attribute. Per the OpenFGA telemetry spec and OTel conventions, some attributes should be numeric:

• http.response.status_code should be int → AttributeKey.longKey()
• http.request.resend_count should be int → AttributeKey.longKey()

Impact

Downstream OTel pipelines (dashboards, alerts) that expect numeric types for these attributes will either fail or treat them incorrectly. For example, queries like status_code >= 400 won't work on string-typed values.

Proposed Fix

In Attributes.prepare(), use AttributeKey.longKey() for known numeric attributes, parsing the string value to long. The internal Map<Attribute, String> representation can stay as strings — only the OTel export needs correct types.

Prior Art

The Python SDK already fixed this same issue in PR #177.

Related

• PR #290 (telemetry instance sharing fix)

Start at src/main/java/dev/openfga/sdk/telemetry/Attributes.java:130 and inspect how Attributes.prepare() converts values for OTel export. Compare the two named HTTP attributes with the OpenFGA telemetry spec and Python SDK PR #177; done means those attributes use numeric OTel types while the internal string map remains unchanged.