Support templating ManagementURL from credential field values (e.g. Endpoint) for self-hosted platforms

[marcleblanc2]

What does it concern?

The plugin SDK, design, or schema

Goal or desired behavior

For platforms that are self-hosted or instance-scoped, the credential management page lives on the user's own instance, not on the vendor's public domain. It would be great if a plugin could declare a management URL template that references one of its credential fields, for example:

ManagementURLTemplate: "{{ .Endpoint }}/settings/tokens",

so that the item created by op plugin init points at the user's actual instance — e.g. https://sourcegraph.example.com/settings/tokens — using the Endpoint value the user just imported or entered.

This would benefit every plugin for a platform with self-hosted or per-instance deployments: Sourcegraph, GitHub Enterprise, GitLab, Artifactory, Okta, and others. Today all of these can only point at the vendor's public cloud domain, which is wrong for self-hosted users.

Current behavior

schema.CredentialType.ManagementURL is a static *url.URL, fixed at compile time. For the Sourcegraph plugin (see #593), it's hardcoded to https://sourcegraph.com/settings/tokens. When a user of a self-hosted instance runs op plugin init src and imports their SRC_ENDPOINT, the resulting 1Password item's website is stamped with the sourcegraph.com URL — the imported Endpoint field is saved correctly and provisioning works, but the management link points at an instance the user may not even have an account on.

There's no workaround from the plugin side: the schema crosses the RPC boundary by serialization, and only the op CLI knows the item's field values at creation time, so the plugin can't compute the URL itself.

A rough sketch of what a fix would involve:

1. A new schema field such as ManagementURLTemplate string, alongside the existing static ManagementURL (kept for platforms with fixed URLs, and as a fallback).
2. A validation rule that the template only references declared, non-secret field names.
3. op CLI support for rendering the template with the item's actual field values when creating the item and when displaying the management URL.

Happy to contribute the SDK/schema and validation side (items 1 and 2) if the approach sounds reasonable — item 3 would need changes in the CLI itself.