chore: promote staging bc1a463 to production

[agentex-sdk-sync]

Automated promote from the staging trunk, opened by stlc-promote.yml.

Approve this pull request - do not click Merge. Squash and rebase both rewrite SHAs, which forks the production trunk away from staging and blocks all codegen until someone reconciles them by hand. Merge commits are disabled on this repo.

Once CI is green here and this has one approval, re-run stlc-promote.yml in the config repo. It fast-forwards main onto these exact commits, GitHub closes this pull request as merged, and the trunks stay byte-identical.

Confidence Score: 4/5

The PR is not safe to merge until the Bandit job checks out fork pull requests correctly.

Findings

1.  Fork PRs cannot run Bandit ▶

Fix with agent prompt

### Issue 1
.github/workflows/bandit-ci.yml:30-31
This fetch uses the base repository's `origin`, but `$GITHUB_HEAD_REF` names the source branch. For a fork pull request, that branch usually exists only in the fork, so `git fetch` exits before the changed-code scan runs. Check out the pull request head SHA or fetch from `github.event.pull_request.head.repo` instead.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

This promotion adds production-only workflow guards, shared security checks, and release automation while keeping the same files usable on staging. It also points the production SDK at the live Agentex service and updates related package and release settings.

• Routes production-only jobs by repository.
• Adds OpenGrep, TruffleHog, and Bandit workflow entry points.
• Connects release automation to the agentex-sdk-sync app.
• Points the production SDK environment at the live service.

Diagram

sequenceDiagram
    actor Contributor
    actor User
    participant GitHub
    participant Bandit
    participant SharedScans as Shared scan workflows
    participant Client as Agentex client
    participant API as agentex.sgp.scale.com
    participant Release as Release job

    Contributor->>GitHub: Open pull request
    par Bandit job
        GitHub->>Bandit: Check out base branch
        Bandit->>GitHub: Fetch head branch from origin
        alt Head branch comes from a fork
            GitHub-->>Bandit: Branch is missing
            Bandit-->>GitHub: Job fails before scan
        else Head branch exists on origin
            Bandit->>Bandit: Compare scan with baseline
            Bandit-->>GitHub: Report results without failing on findings
        end
    and OpenGrep and TruffleHog
        GitHub->>SharedScans: Run reusable workflows
        Note over GitHub,SharedScans: OpenGrep inherits all available secrets
    end

    User->>Client: Create client with default settings
    Client->>API: Send typed API request over HTTPS
    API-->>Client: Return response

    GitHub->>Release: Push reaches main
    Release->>Release: Mint repository write token
    Release->>Release: "Install release-please@16"
    Release->>GitHub: Open release PR or publish release

Loading

_{Reviews (1) · Last reviewed commit: "fix: align the base-URL test with this t..."}

[greptile-apps]

This fetch uses the base repository's origin, but $GITHUB_HEAD_REF names the source branch. For a fork pull request, that branch usually exists only in the fork, so git fetch exits before the changed-code scan runs. Check out the pull request head SHA or fetch from github.event.pull_request.head.repo instead.

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/bandit-ci.yml
Line: 30-31

Comment:
This fetch uses the base repository's `origin`, but `$GITHUB_HEAD_REF` names the source branch. For a fork pull request, that branch usually exists only in the fork, so `git fetch` exits before the changed-code scan runs. Check out the pull request head SHA or fetch from `github.event.pull_request.head.repo` instead.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.