fix: provisioner + signer repro-blockers for local bring-up

[rickstaa]

Three small fixes hit while bringing up this PR's stack (auth0-provisioner + remote-signer) locally. Each is an independent repro-blocker; no functional change to the exchange/provisioning flow.

Fixes

• remote-signer/entrypoint.sh — source the keystore password from SIGNER_ETH_PASSWORD when set. Previously the password was only read from /data/.eth-password, so a password supplied via .env never reached the file and the signer could not unlock its keystore.
• auth0-provisioner/provision/bootstrap.sh — look up the client-grant by client_id only and select the matching audience in jq. The prior raw audience query param went out unencoded and returned a mismatched grant, causing a 409 client_grant_conflict on re-run.
• auth0-provisioner/provision/bootstrap-credentials-exchange-action.sh — accept the auth0 CLI when resolved from PATH (command -v), not just as a local executable ([ -x ]).

Notes

• Based on feat/session-exchange-openmeter-provisioning so it layers directly onto PR feat(builder-api): OpenMeter session exchange with provisioning #57.
• No secrets/config included (.env, override, keystore mount kept local).

[eliteprox]

LGTM! Approved with small nites

[eliteprox]

[.[] | select(.audience==$a) | .id] | first // empty picks an arbitrary match if multiple client-grants exist for the same (client_id, audience) pair, without detecting or reporting the duplication. Failure scenario: since the old unencoded-query bug likely caused previous runs to create duplicate grants instead of finding the existing one (plausibly the actual root cause of the 409 this PR fixes), a tenant carrying that leftover state could now have the script non-deterministically PATCH a different grant on each rerun rather than surfacing the conflict. Worth a guard that errors (or warns) if more than one grant matches.

[eliteprox]

Small nit, you could optionally log what is happening here (without logging any secrets of course).

[eliteprox]

Adopted two of these three into #82, which carries auth0-provisioner/ now that #57 has been split into a reviewable stack (#78 → #79 → #80 → #81 → #82). Attribution kept in the commit message.

Taken:

• bootstrap.sh client-grant encoding. This one matters more than its size suggests. Idempotency is the main argument for keeping this shell provisioner over the Go CLI in feat: Go bootstrap CLI for Auth0 + OpenMeter/Konnect #33, and feat(bootstrap): one-command provisioning + sdk-config emitter #82's own README and script header claim re-running is safe — a claim that was false while the audience went out unencoded and re-runs 409'd. The duplicate-grant hard stop came along with it.
• bootstrap-credentials-exchange-action.sh CLI resolution. Worth spelling out how bad this was: when auth0 is on PATH, command -v succeeds so AUTH0_BIN stays "auth0", and then [ -x "auth0" ] tests a relative path in the working directory and fails. The script died precisely when the CLI was available.

Not taken:

• remote-signer/entrypoint.sh SIGNER_ETH_PASSWORD. Deliberately left here. That bug is on main and no PR in the stack touches remote-signer, so folding it in would have meant this PR getting absorbed and a real fix quietly vanishing with it. It should land on its own — happy to open a small PR for just that if you'd rather not carry this one.

One thing worth a conscious nod when the grant fix is reviewed: ensure_client_grant now calls die internally on duplicate grants, but callers invoke it as ensure_client_grant … || { rollback_app; die … }. Since die exits from within, rollback_app never runs on that path. It reads deliberate to me — a duplicate-grant state wants a human, and rolling back could delete real Auth0 objects — but it is a behaviour change rather than a pure bug fix.