docs: don't duplicate the scope's notification channel for the container-scope-override

[sebastiancorrea81]

Summary

• The README's step 3 example (scope_channel_association) registers a second scope_definition_agent_association-based module call pointed at the same scope_specification_id/scope_specification_slug as the scope's existing agent-association channel.
• The channel's filters are built solely from scope_specification_slug/scope_specification_id (see nullplatform/scopes's k8s/specs/notification-channel.json.tpl). enabled_override only appends --overrides-path=... to the cmdline — it doesn't change the filter.
• So two module calls for the same scope create two nullplatform_notification_channel resources with identical filters: every action notification fires both, duplicating the base entrypoint execution (one of the two additionally runs the override sync).

Change

• Documents adding enabled_override / override_repo_path / overrides_service_path directly to the scope's existing scope_definition_agent_association module call, when one already exists in the project.
• Keeps the original scope_channel_association (for_each) example for the case where the target scope has no existing agent association yet.

Docs-only change, found while wiring path-router into a scope that already had its own agent association.

Test plan

• Reviewed rendered README locally for formatting/link correctness.
• N/A — no code change.