A2A joint lineage: cross-organization IAM + redaction fixture (was 129c)

## Why

Follow-up from [#129](https://github.com/GoogleCloudPlatform/BigQuery-Agent-Analytics-SDK/issues/129). The A2A joint lineage demo currently runs in **one GCP project, three datasets** (`a2a_caller_demo`, `a2a_receiver_demo`, `a2a_auditor_demo`). The auditor's redaction of raw `a2a_request` / `a2a_response` / `content` payloads is enforced **by the projection SELECT lists** (a *convention*), not by IAM. Anyone with project-level access can `SELECT *` from the underlying caller/receiver datasets and see everything the projection drops.

The production cross-organization story — multiple participating orgs, an auditor that should only see redacted lineage — needs an IAM-enforced fixture. This issue tracks that work.

## Scope

Build a real two-project (or three-project) fixture demonstrating:

### Architecture options to evaluate

Three sharing patterns from the #129 plan, in order of decreasing IAM friction:

1. **Cross-dataset property graph** — auditor's project gets `bigquery.dataViewer` on each participating org's audit-scoped views; one `CREATE PROPERTY GRAPH` whose `NODE TABLE` / `EDGE TABLE` clauses span both orgs' datasets via fully-qualified references. Cheapest at query time but most IAM coordination.

2. **Analytics Hub / authorized views** — each participating org publishes a redacted view through Analytics Hub; the auditor subscribes and gets a local copy in their own project. More operationally familiar but adds publish/subscribe latency.

3. **Stitch table only** — each org keeps its own per-org property graph; a shared `joint_a2a_edges` table holds `(a2a_task_id, caller_session_id, receiver_session_id)` rows; auditor queries each graph separately and joins in app code. Simplest data plane, weakest UX.

The current demo's #135 architecture maps cleanest to option 1 (the joint property graph already spans three datasets). Option 1 plus IAM-scoped service accounts is probably the right first cut.

### Concrete deliverables

- [ ] A new sibling demo or `examples/a2a_joint_lineage_demo/` extension that:
- [ ] Provisions caller and receiver datasets in two separate projects.
- [ ] Provisions the auditor dataset in a third project (or auditor's own project).
- [ ] Materializes the joint property graph from cross-project NODE TABLE / EDGE TABLE references.
- [ ] Runs end-to-end with a service account that has *only* auditor-scoped IAM (no `bigquery.dataViewer` on caller/receiver source datasets, only on the redacted auditor projections).
- [ ] Acceptance check: auditor service account can run all five blocks in `bq_studio_queries.gql` and gets identical results to the single-project demo, but `SELECT * FROM .agent_events` returns `403 Permission denied`.
- [ ] `SETUP_NEW_PROJECTS.md` (plural) walking through the three-project setup, IAM grants, and the Analytics Hub or authorized-view publication step.

### Trust boundary

The two-place propagation in this demo assumes:

- Caller honestly stamps `a2a_task_id` / `a2a_context_id`. Spoofing here would let one org claim it delegated to another that never received the call.
- Receiver honestly maps `context_id := session_id`. A malicious receiver could honor this honestly and still produce unfaithful trace data.

Cryptographic signing of A2A task_id is **out of scope**; document the trust assumption in the new SETUP doc.

## Acceptance criteria

- [ ] Two-project (minimum) fixture provisioned and documented.
- [ ] Auditor-scoped service account works end-to-end against the joint property graph.
- [ ] Auditor-scoped service account is denied raw access to caller/receiver source datasets.
- [ ] Block 5 (redaction proof) returns zero rows.
- [ ] `SETUP_NEW_PROJECTS.md` covers IAM, Analytics Hub OR authorized-view publication, and the trust boundary.

## Out of scope

- Cryptographic A2A task_id signing.
- Cross-organization payload encryption at rest (BQ default encryption is sufficient for the demo).
- Cross-ontology concept alignment (separate follow-up).
- Streaming / long-running A2A.

## Related

- Issue #129 — implementation contract for the three merged PRs (#132, #133, #135, #136).
- Companion follow-ups: receiver-side task_id propagation, cross-ontology concept alignment.