docs: plan for lit-triggers (reactive Lit Action runner)

[clawdbot-glitch003]

Summary

Adds plans/lit-triggers.md — a design doc for a new outside-the-TEE service that fires Lit Actions in response to webhooks, EVM/Tron chain events, and cron schedules. Trust model is built around scoped usage API keys (account key is provisioned in the browser and never touches our backend). Doc covers the multi-tenant Postgres schema, chain listener strategy (shared EVM listener for eth/base/arbitrum/bsc/polygon plus a separate Tron implementation), inline-action storage with CID computed via the existing ipfs-hasher crate, and a six-PR delivery plan.

No code changes — planning doc only.

Test plan

• Review the plan and push back on any decisions before PR 1 starts.

🤖 Generated with Claude Code

[GTC6244]

@glitch003 - basically agree with the plan - a couple of points for consideration:

1. The triggers are currently tied to a Chipotle Account. This makes sense for grouping - but we probably need to somehow confirm this, rather than use simple data entry (was unclear about how this is done).
2. Do we want to set up anything around payment for this service ? It's pretty easy to abuse if a webhook is enabled!
3. Alternatively, rate limiting of some sort ?
4. Calling another users' CID with your own Usage key may be possible - if the action in question is generic enough - it would require the second user setting up their own Chipotle account and entering the exact same action code - but might make things a bit confusing ( effectively I can draw some parallels with the mumeration stuff ! ) ... do we want to account for any of this ?

[glitch003]

@glitch003 - basically agree with the plan - a couple of points for consideration:

1. The triggers are currently tied to a Chipotle Account. This makes sense for grouping - but we probably need to somehow confirm this, rather than use simple data entry (was unclear about how this is done).

i think we don't need to fully link auth, just like, this is a place for you to automate your chipotle stuff. and then my idea here (and i just updated the plan to make it more clear, hopefully) was have them enter their admin api key into the site, but, frontend only. the frontend sets up a usage key for them that can only call the group they need. and then the frontend sends the usage key to the backend for storage. so that's how they bind the trigger to their specific chipotle account. and yeah a form with like group id, ipfs cid, etc, as needed. i imagine most ppl will interface with this over API eventually

2. Do we want to set up anything around payment for this service ? It's pretty easy to abuse if a webhook is enabled!
3. Alternatively, rate limiting of some sort ?

yeah def rate limiting per user to start. but let's add charging later, maybe. b/c if a trigger always runs an action thats good for us so this could be a free service.

4. Calling another users' CID with your own Usage key may be possible - if the action in question is generic enough - it would require the second user setting up their own Chipotle account and entering the exact same action code - but might make things a bit confusing ( effectively I can draw some parallels with the mumeration stuff ! ) ... do we want to account for any of this ?

i think we can come back to this