feat: language parity for accumulated context governance (TypeScript, .NET, Rust, Go)

## Summary

#2797 proposes governing the **accumulated** context of a multi-agent workflow, so AGT can check an action or a delegation against the running state of everything the workflow has touched, not just the request in front of it. The agreed v1 scope is an in-process accumulated context envelope (the broader receipt / signed-chain model is deferred to a follow-up). The first cut lands in **Python**. This issue tracks bringing the same capability to the other AGT language SDKs once the Python surface settles.

## What Python adds (#2797)

- A `ContextEnvelope`: an immutable, versioned value holding the labels accumulated so far, an aggregate sensitivity (the max over the data classification ladder), and a grow-only set of restrictions.
- Aggregation rules over label combinations, with a backstop so a combination nobody wrote a rule for escalates for review instead of slipping through.
- Restriction inheritance on delegation, so a delegated agent cannot quietly lose the constraints its parent was working under.
- Reuse of the existing Python primitives in `agent_os/policies/data_classification.py` (DataClassification, DataLabel, ABACPolicy).

## Gap in other SDKs

The accumulated-context model does not exist outside Python today. The data classification vocabulary it builds on is also Python-anchored, so each SDK needs both the classification primitives and the envelope on top:

| SDK | Path | Current state |
|-----|------|---------------|
| TypeScript | `agent-governance-typescript/` | policy evaluation only, no data classification or context envelope |
| .NET | `agent-governance-dotnet/` | policy decision model only, no data classification or context envelope |
| Rust | `agent-governance-rust/` | policy evaluation only; #2797 notes the core policy engine already carries `result_labels` on a verdict, which is a useful starting point, but there is no workflow-scoped accumulated envelope |
| Go | `agent-governance-golang/` | policy evaluation only, no data classification or context envelope |

## Proposed work

Once the Python first cut lands and the envelope surface is stable, for each SDK:

- add (or reuse) a data classification and label vocabulary
- add a workflow-scoped, immutable, versioned context envelope that accumulates labels, tracks an aggregate sensitivity, and carries a grow-only restriction set
- evaluate actions and delegations against the envelope, with the escalate-on-unknown-combination backstop
- inherit restrictions across delegation
- add tests covering accumulation, the unknown-combination backstop, and delegation inheritance

One PR per language keeps each change reviewable. Where an SDK does not yet have the delegation or classification surface this builds on, note it and scope that as its own prerequisite rather than forcing it.

## References

- Source feature: #2797 (Python design and v1 scope decision)
- Parity precedent: #2986, #2537

Start with #2797 to understand the settled Python envelope surface, then inspect the relevant SDK directory: agent-governance-typescript/, agent-governance-dotnet/, agent-governance-rust/, or agent-governance-golang/. Identify the existing policy, classification, and delegation primitives before choosing one language; done means the SDK has an immutable accumulated envelope, unknown-combination escalation, restriction inheritance, and tests for accumulation and delegation.

Written by the indexing model from the issue text.