feat(providersv2): add path auth_style

[Cali0707]

Summary

While looking through the proposal in #896 I saw that we never added the auth_style: path that was outlined. This PR looks to close that gap

Related Issue

Part of #896

Changes

• Add path_template to CredentialProfile in protobuf and associated types
• Add handling for auth_style: path validation

Testing

• mise run pre-commit passes
• Unit tests added/updated
• E2E tests added/updated (if applicable)

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable)

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[Cali0707]

Note that adding this path auth_style leaves an open design decision for providers v1:

Bearer, header, and query injection all work transparently - the proxy adds a header or query param to the outbound request without the sandbox process needing to know the credential.

Path injection is different as the credential is embedded in the URL the process constructs (e.g. Telegram /bot/sendMessage). If the process doesn't have credentials in it's environment, it probably can't construct the URL.

A couple ideas:

1. Path-style stays placeholder based (unlike non-path style auth).
2. Maybe some providers are okay if the value is unset and we just "correct" the value after?
3. Something else?

We may want to figure this out before merging here, to make sure that this approach even works with the v2 providers design

[johntmyers]

I would lean option 1. On that note, I think we should require the placeholder i.e. /bot{token} otherwise as it stands the path_template could have any arbitrary string.

The user-facing docs also need to be updated with the path support and indicate what requirements there should be in the path template.