refactor!: Remove cross-region CWL routing from log config options

[MarinMaksutaj]

What was the problem/requirement? (What/Why)

#997 (a3ce25c) added cross-region CloudWatch Logs routing: the worker agent reads a region from the log configuration options and routes session logs to that region. This code is redundant: workers already route session logs to the home region by default today, so the extra region handling is not needed.

What was the solution? (How)

Remove the cross-region routing added in #997. This is mostly a revert, but not a pure one, which is why it is typed refactor! rather than revert:

Removed (from #997):

• The region key in the log configuration options and all handling of it
• Region parameter threading through construct_worker_log_config, LogConfiguration, and the CloudWatch Logs client creation in the entrypoint
• The unit tests covering the region option

Kept (from #997):

• The log_constants.py extraction (minus the region key). feat(mrf): Use region from log config options for cross-region CWL ro… #997 moved the log config option key constants out of log_sync/cloudwatch.py into a leaf module, which broke a module-level cyclic import chain (sessions/log_config -> log_sync/cloudwatch -> scheduler). A pure revert reintroduces that cycle and CodeQL flags it with 5 errors. cloudwatch.py re-exports the constants for backwards compatibility.

What is the impact of this change?

The worker agent no longer honors a region in the log configuration options; CloudWatch Logs clients use the default routing.

How was this change tested?

Unit tests (3047 passed), ruff check, ruff format, and mypy all pass.

Was this change documented?

No documentation changes needed; the removed option was not documented.

Is this a breaking change?

Yes.

BREAKING CHANGE: the worker agent no longer honors a region in the log configuration options; CloudWatch Logs clients use the default routing.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

Release tooling will silently drop this breaking change from the CHANGELOG.

The commit subject is revert!: ..., but revert is not in allowed_tags in pyproject.toml:241-252. python-semantic-release ignores commits whose type is not in allowed_tags, so this commit will not produce a CHANGELOG entry and (on its own) will not trigger a version bump.

This is not hypothetical — every prior revert: commit in this repo is absent from CHANGELOG.md:

• revert: Revert "chore: remove MANIFEST_REPORTING_FEATURE code (#855)" (#864)
• revert: Revert "test(debug): add e2e pytest session timeout ... (#793)" (#813)

That matters more than usual here because the feature being removed was shipped and announced. CHANGELOG.md:20 (v0.31.0) says:

Cross-region CloudWatch Logs routing now uses the region specified in log configuration options, enabling proper log delivery for multi-region fleet configurations. (#997)

So as things stand, 0.31.0 advertises the feature, and the release that removes it says nothing — leaving users who configured a region log option with no signal that the agent has stopped honoring it. The BREAKING CHANGE: trailer in the commit body does not rescue this, since the commit type is filtered out before the trailer is considered.

Options, roughly in order of least churn:

1. Retype the subject to an allowed tag that carries the semantics, e.g. fix!: or refactor!:, keeping the BREAKING CHANGE: trailer so it lands in the CHANGELOG.
2. Add revert to allowed_tags (and probably patch_tags) if reverts should be first-class going forward — this also fixes the general case rather than just this PR.

Worth confirming against your release process which you prefer; either way the current subject means the removal ships unannounced.

[godobyte]

Please check prior revert PR and follow the revert commit convention. The title should show up as revert with the prior commit.

e.g. #813

[godobyte]

Could you update PR description to follow the PR template.