DeployLifecycle emits MaxListenersExceededWarning with >10 scopes (one deploy:start/deploy:end listener per Scope, cap never raised)

## Summary

Every component `Scope` registers a `deploy:start` and `deploy:end` listener on the singleton `deployLifecycle` emitter (`components/Scope.ts`, plus `componentLoader.ts`). `DeployLifecycle` never raises the default `EventEmitter` cap, so any instance with more than ~10 scopes (built-ins + a few plugins/sub-scopes) emits on startup:

```
(node:1) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 deploy:start listeners added to [DeployLifecycle]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
(node:1) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 deploy:end listeners added to [DeployLifecycle]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
```

Observed on harper-pro 5.2.3 with one user application (which loads a handful of sub-scopes) + `status-check`; repeats on every worker start. Listeners are removed on scope teardown (`off` in `Scope.ts`/`componentLoader.ts`), so this is a cap problem, not a leak — but the warning says "memory leak" and trains operators to ignore that class of warning.

## Fix

`this.setMaxListeners(…)` in the `DeployLifecycle` constructor — either a generous fixed bound (the replication `databaseEventsEmitter` uses 1000 for the same reason) or one derived from the number of loaded scopes. `deployLifecycle.ts` already documents the one-listener-per-scope design, so the cap should follow from it.

Start in deployLifecycle.ts and inspect the DeployLifecycle constructor, then review the per-scope listener registration and teardown in components/Scope.ts and componentLoader.ts. Reproduce startup with more than 10 scopes and verify the warning is gone while listeners are still removed during scope teardown.

Written by the indexing model from the issue text.