Indent CHANGELOG continuation lines for repo consistency

The wrapped bullet added by this PR used non-indented continuation
lines. Surveying every wrapped bullet in the repository shows that is
the sole exception:

  CHANGELOG.md                        59 indented, 0 non-indented
  durabletask-azuremanaged/CHANGELOG  20 indented, 0 non-indented
  azure-functions-durable/CHANGELOG   26 indented, 0 non-indented

Indent the nine continuation lines to match. Content is unchanged --
the diff is exactly 18 added space characters (9 lines x 2).

Note the rendering rationale offered in review does not apply here.
CommonMark lazy continuation keeps unindented paragraph text inside
the list item, and GitHub's own renderer returns byte-identical HTML
for both forms (1 <ul>, 1 <li>, no text escaping the item). The reason
to indent is consistency with the other 105 wrapped bullets, not a
rendering defect. Indented text is still more robust, since a future
reflow that starts a line with "-" or "1." would silently open a new
list block.

Longest line is now 89 characters, within the md013 limit of 100.
Violation count is unchanged at 16, all pre-existing and none on the
lines this PR touches.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b6ec6f9e-f919-4874-b146-fa764b5c5617

Author: Bernd Verst

CHANGELOG.md

@@ -14,15 +14,15 @@ ADDED
 CHANGED
 
 - Importing `durabletask` no longer eagerly imports the worker implementation and its
-dependencies (gRPC, protobuf, entities, serialization, OpenTelemetry). The public names
-re-exported from the package — `ActivityWorkItemFilter`, `ConcurrencyOptions`,
-`EntityWorkItemFilter`, `GrpcChannelOptions`, `GrpcRetryPolicyOptions`,
-`LargePayloadStorageOptions`, `OrchestrationWorkItemFilter`, `PayloadStore`,
-`VersioningOptions`, and `WorkItemFilters` — are now resolved on first use, so
-`import durabletask` is substantially faster and loads far fewer modules. This
-measurably reduces cold-start time for client-only applications, including those using
-`durabletask.azuremanaged`, which shares the same `durabletask` namespace. All existing
-import paths, `__all__`, `dir()`, and star-imports behave exactly as before.
+  dependencies (gRPC, protobuf, entities, serialization, OpenTelemetry). The public names
+  re-exported from the package — `ActivityWorkItemFilter`, `ConcurrencyOptions`,
+  `EntityWorkItemFilter`, `GrpcChannelOptions`, `GrpcRetryPolicyOptions`,
+  `LargePayloadStorageOptions`, `OrchestrationWorkItemFilter`, `PayloadStore`,
+  `VersioningOptions`, and `WorkItemFilters` — are now resolved on first use, so
+  `import durabletask` is substantially faster and loads far fewer modules. This
+  measurably reduces cold-start time for client-only applications, including those using
+  `durabletask.azuremanaged`, which shares the same `durabletask` namespace. All existing
+  import paths, `__all__`, `dir()`, and star-imports behave exactly as before.
 - **Breaking:** `FailureDetails.error_type` — and the `errorType` value sent over the wire — is now the fully-qualified type name (`module.ClassName`, e.g. `builtins.ValueError`, `durabletask.task.TaskFailedError`) instead of the bare class name, matching the .NET and Java SDKs. Code that compared `error_type` against a bare name (for example `== "ValueError"`) must be updated to the qualified name or, preferably, switched to `FailureDetails.is_caused_by()`. Because this value is persisted and crosses the orchestration boundary, failures produced by older workers may still carry a bare name; `is_caused_by()` accepts both.
 
 ## v1.8.0