Feature request: expose CPA build version to native plugins

[origin652]

Background

Native plugins sometimes need to adapt their behavior to the actual version of the running CLIProxyAPI (CPA) host.

A CPA release can include changes observable by plugins, for example:

• adding or changing a host callback;
• changing when or where a lifecycle hook is invoked;
• adding fields to request, response, or usage data; or
• fixing host behavior that affects a plugin's result.

When a plugin must remain compatible with both newer and older CPA builds, it needs a reliable runtime way to determine the host version and select the appropriate compatibility path.

Current limitation

Native plugins receive the host callback table, but there is currently no stable plugin-protocol endpoint that reports the build version of the running CPA instance.

The alternatives are not suitable:

• Inferring host behavior from the result of a completed request is too late for logic that must decide before request handling, and can be unreliable under concurrency.
• Guessing from HTTP endpoints, response headers, or external resources makes a plugin depend on management authentication, network access, or non-plugin-protocol interfaces.
• Adding a capability flag for every host behavior change would make the plugin protocol grow continuously with individual fixes and increase maintenance burden.

Request

Please add a backward-compatible host callback, for example:

host.build_info

It would take no request body and return a small, stable response such as:

{
  "version": "v7.2.102",
  "commit": "90c2ff90de39908d145be413ee1346fd5a8b7a55"
}

Where:

• version is the authoritative value for plugin compatibility decisions;
• commit is optional and intended only for diagnostics and troubleshooting, not normal behavior selection;
• this is an additive, optional host callback, so the existing ABI and schema versions need not change; and
• an older CPA build that does not implement the callback simply fails the call, allowing a plugin to safely retain its legacy compatibility path.

Expected use

A plugin would query and cache build info during loading or initialization, then maintain only the version compatibility rules it needs:

valid host version available -> use the behavior appropriate to that version
unknown, invalid, or unsupported host version -> use conservative compatibility behavior

This keeps CPA release versions as the contract for observable host behavior. Plugins do not need to guess implementation details or require a growing set of capability names for individual changes.

Custom builds

For forks, custom builds, or backported patches, the build version should reflect the behavior compatibility baseline of that build.

If a plugin cannot obtain a valid, parseable version, it should conservatively use its compatibility behavior rather than infer the presence of a change from commits, response contents, or other indirect signals.