feat: migrate from Cedar to SpiceDB authorization system

This is a major architectural change that replaces the Cedar policy-based
authorization system with SpiceDB's relation-based authorization.

Key changes:

- Migrate from Rust to Go implementation
- Replace Cedar policies with SpiceDB schema and relationships
- Switch from envoy `ext_authz` with Cedar to SpiceDB permission checks
- Update build system and dependencies for Go ecosystem
- Maintain Envoy integration for external authorization

This change enables more flexible permission modeling through SpiceDB's
Google Zanzibar inspired relation-based system, supporting complex
hierarchical permissions that were difficult to express in Cedar.

Breaking change: Existing Cedar policies and Rust-based configuration
will no longer work and need to be migrated to SpiceDB schema.

1 files changed, 43 insertions, 0 deletions

diff --git a/vendor/github.com/rs/zerolog/CONTRIBUTING.md b/vendor/github.com/rs/zerolog/CONTRIBUTING.md
new file mode 100644
index 00000000..a09e9e21
--- /dev/null
+++ b/vendor/github.com/rs/zerolog/CONTRIBUTING.md
@@ -0,0 +1,43 @@
+# Contributing to Zerolog
+
+Thank you for your interest in contributing to **Zerolog**!
+
+Zerolog is a **feature-complete**, high-performance logging library designed to be **lean** and **non-bloated**. The focus of ongoing development is on **bug fixes**, **performance improvements**, and **modernization efforts** (such as keeping up with Go best practices and compatibility with newer Go versions).
+
+## What We're Looking For
+
+We welcome contributions in the following areas:
+
+- **Bug Fixes**: If you find an issue or unexpected behavior, please open an issue and/or submit a fix.
+- **Performance Optimizations**: Improvements that reduce memory usage, allocation count, or CPU cycles without introducing complexity are appreciated.
+- **Modernization**: Compatibility updates for newer Go versions or idiomatic improvements that do not increase library size or complexity.
+- **Documentation Enhancements**: Corrections, clarifications, and improvements to documentation or code comments.
+
+## What We're *Not* Looking For
+
+Zerolog is intended to remain **minimalistic and efficient**. Therefore, we are **not accepting**:
+
+- New features that add optional behaviors or extend API surface area.
+- Built-in support for frameworks or external systems (e.g., bindings, integrations).
+- General-purpose abstractions or configuration helpers.
+
+If you're unsure whether a change aligns with the project's philosophy, feel free to open an issue for discussion before submitting a PR.
+
+## Contributing Guidelines
+
+1. **Fork the repository**
+2. **Create a branch** for your fix or improvement
+3. **Write tests** to cover your changes
+4. Ensure `go test ./...` passes
+5. Run `go fmt` and `go vet` to ensure code consistency
+6. **Submit a pull request** with a clear explanation of the motivation and impact
+
+## Code Style
+
+- Keep the code simple, efficient, and idiomatic.
+- Avoid introducing new dependencies.
+- Preserve backwards compatibility unless explicitly discussed.
+
+---
+
+We appreciate your effort in helping us keep Zerolog fast, minimal, and reliable!