prefer static TransformerName for custom transformer name resolution

[gigi206]

Problem

When a transformer is registered from a file via transformers: [{ path }], ccr uses instance.name as the registry key. The built-in convention in registerDefaultTransformersInternal is to prefer static TransformerName when present, and only fall back to instance.name.

This inconsistency bites users who mirror the built-in pattern in their custom transformer:

class OpenCodeOpenAIBearerTransformer {
  static TransformerName = "opencode-openai-bearer"; // for config refs
  name = "OpenCodeOpenAIBearer";                     // runtime identity
  endPoint = "/v1/chat/completions";
  // ...
}
module.exports = OpenCodeOpenAIBearerTransformer;

Config:

{
  "transformers": [
    { "path": "/path/to/opencode-openai-bearer.js" }
  ],
  "Providers": [{
    "name": "opencode-openai",
    "transformer": { "use": ["opencode-openai-bearer"] }
  }]
}

Result: the transformer is registered as OpenCodeOpenAIBearer (instance.name), but the config references opencode-openai-bearer (TransformerName). getTransformer("opencode-openai-bearer") returns undefined, the array entry is filtered out, and the provider has an empty transformer list, silently, with no log to point at the cause.

Fix

Use the same name resolution order in registerTransformerFromConfig as in the built-in path: prefer static TransformerName, fall back to instance.name. The error message is also clarified to mention both.

Empirically verified by reproducing the bug locally with a transformer whose name and TransformerName differ. Before the patch, the registry logs register transformer: OpenCodeOpenAIBearer and the provider's use array is silently empty. After the patch, it logs register transformer: opencode-openai-bearer and the provider correctly resolves the transformer.

Compatibility note

A custom transformer that defined static TransformerName = "X" and name = "Y" (different values), and that was referenced as "Y" in user configs, would now be registered as "X" instead. This is intentional realignment with the documented built-in pattern, but worth mentioning in case downstream users have come to rely on the previous behaviour.