fix(proto): carry Orbit token authorization decisions

What does this MR do and why?

Orbit's stream protocol now carries the five values needed for token checks and graph-status replies. Each value uses a new field tag, while all existing fields and tags remain unchanged. This protocol contract must ship before the GKG and Rails behavior changes.

Request flow

1. Rails authenticates the token and sends Orbit a signed JWT with token_authorization_required: true. The JWT contains no raw token or grants.
2. Orbit identifies the required permissions and asks Rails to check them through Workhorse.
3. Workhorse forwards the original credentials to the internal Rails callback.
4. Rails checks the token’s saved grants and returns allow/deny decisions for each permission and resource.
5. Orbit uses those decisions to filter query inputs. Final resource checks also enforce the user’s existing abilities.

Related Issues

• Followed by compiler MR !2416 and server MR !2409.

• Relates to fine-grained token issue 992.

• Uses the Workhorse stream pattern from GitLab MR !229394.

• Relates to the hidden aggregate-input risk in Orbit issue 347.

Testing

The Go generation check, Go build, and Ruby gem build pass. All three existing redaction tests pass. Clippy passes with all features and targets. The MR pipeline passes.

Performance Analysis

This MR adds optional protocol fields and generated bindings. It sets classic redaction requests to the existing empty permission and false boundary-check defaults.

• This merge request does not introduce any performance regression.

Agent context

The five fields are:

• a graph-status request and response in the stream envelope.
• a boundary-check flag in redaction requests.
• a token permission in each resource check.
• an ability in each authorization result.

The change keeps the prior fields and their numeric tags. It adds tags 5 and 6 to the stream envelope. It also adds one unused tag to each redaction message. The MR includes the generated Rust and Go bindings.

Existing redaction requests set the new permission to empty and the boundary flag to false. These classic defaults preserve the prior wire values and compile against the generated fields.

The Ruby binding is built from this protocol during the existing gem job. The existing publish job runs only for a release tag in the canonical project. Package publication remains a separate release step.

Merge this MR first. Use the normal release process to publish the protocol gem. Deploy the GKG behavior MR next. The Rails MR can then pin the published gem and deploy last. Local gem paths and Go replacements are not part of this plan.