Use Buf to guard protobuf schema compatibility

[jwils]

Why

Stable field numbers prevent protobuf data from being reinterpreted, but they do not catch incompatible field-type, syntax, package, or file-option changes. Maintaining those compatibility rules ourselves would duplicate Buf and leave room for subtle gaps.

What

• Add proto_schema_version, defaulting to 1, and record it in the generated schema.proto.
• Compile the existing and proposed schemas with Buf and apply its strict FILE breaking rules before dumping a changed artifact at the same version.
• Reuse one logical proto path for both Buf images so file-level changes are compared accurately, while resolving external imports through the project Buf configuration and excluding imported schemas from the comparison.
• Allow an explicit version bump to accept a breaking change, with a prototyping-only enforce_proto_schema_version false escape hatch.
• Install Buf 1.72.0 for the CI job that validates README examples and document the workflow.

Risk

This adds a development-time dependency on the Buf CLI whenever an existing schema.proto changes without a version bump. First-time generation and explicitly versioned breaking changes do not invoke Buf. Projects can temporarily disable enforcement while prototyping.

Test plan

• script/run_gem_specs elasticgraph-proto_ingestion: 101 examples, 100% line and branch coverage.
• Real Buf 1.72.0 smoke checks: compatible additions pass; field-type and file-option changes fail; imported types compile successfully.
• script/lint, script/type_check, script/spellcheck, documentation coverage, workflow/config validation, README snippet validation, and site:validate.
• script/quick_build: 5,291 of 5,292 examples passed; one unrelated datastore acceptance example observed a record from another test environment and passed immediately when rerun in isolation.

References

• Stacked on Source enum values from external proto enums and reference external enum types #1286.
• Follow-up to the Buf compatibility discussion.