Emit gen_ai.agent.name alongside agent.name on LLM spans #126

Context

Follow-up from #125, which adds the OTel GenAI token and model attributes to
LLM spans. One gap remains for consumers that read the GenAI conventions.

What happens now

The LLM span carries the agent under the OpenInference key only:

agent.name = build        # opencode's internal agent (build / plan / a subagent name)
agent.type = primary

There is no gen_ai.agent.name, so a consumer reading GenAI conventions sees
the provider, model and token usage but no agent attribution — it cannot tell
a build request from a plan request or from a named subagent.

Proposal

Mirror it the same way #125 mirrors the token attributes — additive, nothing
renamed:

gen_ai.agent.name    <- agentName

@opentelemetry/semantic-conventions already exports
ATTR_GEN_AI_AGENT_NAME (gen_ai.agent.name), and the package is already a
dependency. ATTR_GEN_AI_AGENT_ID and ATTR_GEN_AI_AGENT_VERSION also exist
if they turn out to be worth populating; agent.type has no GenAI equivalent
and would stay as-is.

A distinction worth keeping

Some backends use a field called agent for the coding assistant itself
(claude-code, gemini-cli, and so on) rather than an agent within it. This
plugin's agent.name is not that — it is opencode's internal agent — so it
should not be mapped onto such a field.

That identity is already carried correctly on the resource as
service.name = opencode, which seems like the right place for it. Anyone
whose backend keys on a bare agent attribute can set it today without a code
change:

"spanAttributes": "agent=opencode"

Flagging it because conflating the two would silently misattribute every
request, and the naming makes that easy to do.

Happy to send a PR

Small and shaped exactly like #125 if you want it.