Copy ssm_secrets.py into Phase 2 Lambda image (unblocks DataPhase2)

[cipher813]

Summary

Tonight's pipeline rerun passed DataPhase1, RAG, and Research cleanly (validating #13 macro-breadth fix + #15 Step Function HandleFailure fix end-to-end), but DataPhase2 failed with:

```
Runtime.ImportModuleError: No module named 'ssm_secrets'
```

Root cause

`lambda/handler.py:22` does `from ssm_secrets import load_secrets` at module top-level, but the Dockerfile never copied `ssm_secrets.py` into the image. The pre-#14 image was built manually at a time when this import didn't exist, so it ran fine for ages. #14's GitHub Actions auto-deploy rebuilt the image from the current Dockerfile, published version 2, and flipped the `live` alias before the canary step failed on an unrelated IAM permission — so the alias is now stuck on the broken v2.

Verified:
```
aws lambda get-alias --function-name alpha-engine-data-collector --name live
FunctionVersion: 2
LastModified: 2026-04-11T00:51:38Z (mid-#14-deploy)
```

Fix

Add `COPY ssm_secrets.py ${LAMBDA_TASK_ROOT}/` to the Dockerfile. Audited both `lambda/handler.py` and `collectors/alternative.py` import graphs via AST walk — the only first-party modules pulled in at handler import time are `collectors` (already copied) and `ssm_secrets` (now copied). `ssm_secrets.py` itself only imports stdlib (`logging`, `os`), so no transitive issues.

Also added `ssm_secrets.py` and `lambda/**` to the deploy workflow's `paths` filter — both were missing, which means changes to `handler.py` or the secrets loader would silently not retrigger a Lambda rebuild.

Test plan

• `pytest tests/ -q` — 61 passed
• Gitleaks pre-commit pass
• AST audit of handler + alternative imports confirms `ssm_secrets` is the only missing first-party dep
• After merge + auto-deploy, verify `aws lambda invoke alpha-engine-data-collector:live --payload '{"phase": 2, "dry_run": true}'` returns OK
• Redrive the failed Step Function execution `manual-recovery-20260411T010521Z` from DataPhase2

Known follow-up (NOT in scope)

The GitHub Actions OIDC role `github-actions-lambda-deploy` lacks `lambda:InvokeFunction` + (implicitly) `lambda:UpdateAlias` on `alpha-engine-data-collector:live`. That's why `infrastructure/deploy.sh`'s canary step has failed after every auto-deploy since #14 landed, and the post-canary rollback path also silently fails — stranding the alias on whatever version just got published. The Lambda still gets updated because `UpdateFunctionCode` succeeds first; the canary is a post-update safety check. Two fixes possible:

1. Add `lambda:InvokeFunction` + `lambda:UpdateAlias` on the data-collector Lambda ARN to the OIDC role
2. Short-circuit the canary step when running in CI (`[ -n "$CI" ] && skip`)

Either way, that's a separate infrastructure PR. Tonight's manual canary can run from the local AWS creds after this PR merges.

🤖 Generated with Claude Code