Fix deployment.yaml secret key mismatches and channel name

[Usman Sohail (Usman0626)]

Found while deploying and testing this project against a real local
Kubernetes cluster (minikube). All three fixes were verified by actually
redeploying with the corrected values and confirming the pod reaches
Running/Healthy and the app correctly starts.

• LANGSMITH_RUNS_ENDPOINTS secretKeyRef doesn't match anything in the codebase; main.py reads and requires LANGSMITH_API_KEY instead.
• LC_GATEWAY_KEY, ANTHROPIC_BASE_URL, SLACK_BOT_TOKEN, SLACK_APP_TOKEN are documented as optional in README/.env.example but were missing optional: true on their secretKeyRefs, causing CreateContainerConfigError when omitted.
• Default SLACK_CHANNEL value used underscore (#sre_alerts) instead of the hyphenated convention used in .env.example (#sre-alerts).

[Usman Sohail (Usman0626)]

While testing this against a real local minikube cluster I ran into a few more things worth flagging. Issue creation looks restricted on this repo so posting them here instead.

README mentions k8s/postgres.yaml for durable state (checkpoints, sessions, HITL audit log, monitoring history) but this file doesn't actually exist anywhere in the repo, I checked with find . -iname "postgres" and got nothing. Also kustomization.yaml never references it either, so even the documented one-command deploy (kubectl apply -k k8s/) would never create it even if the file did exist. End result is deploying exactly as documented just quietly falls back to in-memory state, which to be fair the app does report honestly through /health (durable_state: false), but there's no actual path in the docs to get real durable state working. I don't know your intended design here (image, storage class, resource limits) so didn't want to just guess and submit a StatefulSet, but happy to take a crack at it if that's useful.

Same kind of thing with k8s/secret.yaml, the README tells you to paste your values into it but there's no template or example file for it anywhere, not even a .example version. Ended up having to manually go through deployment.yaml's secretKeyRefs to figure out what keys it actually wants. Would be a quick fix to add a secret.yaml.example matching the same key names already used in .env.example.

Last one, requirements.txt doesn't pin anything, it's all >= (or nothing at all for a couple packages like deepagents). The contributing guide for this org actually says repos need a lockfile like uv.lock for exactly this reason, so this seems like it's just been missed. Can generate a pinned version or a uv.lock if that's what you'd want, wasn't sure which you'd prefer so didn't want to just open a PR guessing.