Add consensus signing demo

[natefikru]

Summary

• Add a Rust example (consensus_demo) that provisions demo resources (Ed25519 private key, agent user, consensus policy) via the Turnkey Rust SDK
• Add sign.sh script that drives the tk CLI (tk ssh public-key, tk ssh git-sign) to trigger a consensus-gated signing request
• Approval is done via tk activity approve <fingerprint> with root credentials
• Teardown cleans up all demo resources and artifacts

Files changed

• tk/examples/consensus_demo.rs: Setup and teardown subcommands using turnkey_client directly
• scripts/consensus-demo/sign.sh: Shell script that sources agent credentials and signs via tk CLI
• docs/consensus-demo.md: Step-by-step walkthrough of the full demo flow
• tk/Cargo.toml: Added serde and turnkey_client dev-dependencies for the example
• README.md, tk/README.md: Added link to consensus demo docs

How to test

export TURNKEY_ORGANIZATION_ID="<ORG_ID>"
export TURNKEY_API_PUBLIC_KEY="<PUBLIC_KEY>"
export TURNKEY_API_PRIVATE_KEY="<PRIVATE_KEY>"

cargo run -p tk --example consensus_demo -- setup
./scripts/consensus-demo/sign.sh
cargo run -p tk -- activity approve <fingerprint>
cargo run -p tk --example consensus_demo -- teardown

[natefikru]

Stacked on top of #17.

This PR contains only the Rust demo/doc changes and uses the Rust SDK directly for setup/teardown instead of shell scripts.

[emostov]

Lets make this follow a similar format to how the rust SDK examples work: https://github.com/tkhq/rust-sdk/tree/main/examples

After thinking about it for a little bit, I want to try and keep the demo logic as simple as possible. I think to do this we should have the examples assume there are two static toml config files, one for a human root user and one for an agent. They would both be part of the same org, but the human is a root user while the agent is a non-root user. Similar to the rust SDK examples, the setup for both can be manual.

So the actual script would just be a single main function

• load configs for human and agent
• create a consensus policy that requires two approvers (can be super simple since we just want the agent request to return consensus needed)
• shell out to the CLI to do git-sign with the agent (use env override to specify path to agent config toml)
• take the activity id returned in the result of the git-sign error and use that shell out to the CLI to call activity approve from the human

And thats it. I think we don't need to worry about cleanup for now (its just the policy in this case). Once we get the CLI commands for resource create/delete we can show how to use them to setup an org such that it can be used for this demo, but I don't think that should be automated