fix(sandbox-daemon): don't panic on Classify(nil, nil)

[pedrofrxncx]

Bug found while auditing packages/sandbox/daemon-go/internal/config for malformed-input handling in Classify.

Classify(before, after *TenantConfig) handles a nil before via nil-safe accessor methods (HasCloneUrl(), Branch(), etc. all check c == nil first) everywhere except one arm: when before == nil and no meaningful field is present, it calls diffEnv(nil, after.Env) — a bare struct-field access on after. If after is also nil, that's a nil-pointer dereference panic, not a graceful no-op like the otherwise-symmetric Classify(nil, &TenantConfig{}) case (which the existing test suite already covers and returns KindNoOp for).

Classify is exported from the config package and its only current caller (Store.apply in store.go) always passes a non-nil after (the result of DeepMerge, which never returns nil), so this isn't reachable in production today — but it's a real crash-on-misuse footgun in an exported API, and the fix is a one-line normalization plus a regression test.

Fix: normalize after to &TenantConfig{} at the top of Classify when nil, matching how before is already handled — Classify(nil, nil) now returns KindNoOp, consistent with Classify(nil, &TenantConfig{}).

Reviewer check: cd packages/sandbox/daemon-go && go test ./internal/config/...

Verified locally: gofmt -l, go vet ./internal/config/..., go test ./internal/config/... (all pass). Full CI covers the rest of the daemon.

---

Summary by cubic

Fixes Classify(nil, nil) in packages/sandbox/daemon-go/internal/config from panicking on a nil-pointer dereference to returning KindNoOp, matching the existing behavior for Classify(nil, &TenantConfig{}). The bug wasn't reachable from the current caller (Store.apply always passes a non-nil after), but it was a crash-on-misuse footgun in an exported API.

^{Written for commit fa2888d. Summary will update on new commits.}

[pedrofrxncx]

Closing as stale: this PR sat past the bot's 48h merge window, main has moved on, and its CI results no longer reflect the current base. This is a housekeeping close, not a rejection of the change — if the underlying problem still exists, the bot will find it again and open a fresh, rebased PR.

[studio-bot:stale-close]