[fix](be) Restore mutable ownership in COW paths

[zclllyybb]

What problem does this PR solve?

Issue Number: N/A

Related PR: N/A

Problem Summary: assume_mutable now asserts exclusive ownership, so paths that moved columns out of blocks or borrowed shared subcolumns must return ownership explicitly or mutate through owning COW handles. This restores COW-safe mutation in block reuse, variant extraction, parquet/orc conversion, memtable aggregation, compaction readers, result buffering, and affected BE unit tests.

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[zclllyybb]

run buildall

[zclllyybb]

/review

[github-actions]

I found a blocking COW correctness issue in complex-type deserialization. The PR changes these paths from mutating the existing child through assume_mutable() to mutating a possibly cloned child, but the cloned child is not written back to the parent complex column. That means deserialization can update offsets while dropping child data when nested children are shared, which is exactly the ownership case this PR is trying to make safe.

Critical checkpoint conclusions:

• Goal/test: The goal is to restore COW-safe mutation after assume_mutable() enforces exclusive ownership. The broad BE unit-test list helps, but the complex-type deserialize path still has an uncovered shared-child case.
• Scope/focus: The change is focused on COW ownership, but several deserialize updates need the same write-back pattern used elsewhere after mutating detached children.
• Concurrency/lifecycle/config/compatibility: No new concurrency, lifecycle, configuration, or storage-format compatibility concern identified in the reviewed changes.
• Parallel paths: Array, Map, and Struct deserialize have the same detached-child pattern and all need to be fixed consistently.
• Tests: Please add or adjust coverage for deserializing complex columns whose child ColumnPtr is shared so this does not regress.
• Observability/persistence/write correctness/performance: No additional observability, persistence, transaction, or performance blocker found beyond the data-correctness issue above.

User focus: No additional user-provided review focus was specified.

[github-actions]

This now mutates a local nested_column, but if get_data_ptr() is shared, mutate() clones the child and deserialization fills only that clone. Since the clone is never assigned back to the ColumnArray, the array keeps the old child while offsets have already been resized/copied, producing an inconsistent deserialized array. Please store nested_column back into data_column->get_data_ptr() after get_nested_type()->deserialize(...).

[github-actions]

Same COW ownership issue here: mutate() may return cloned key/value children when the map subcolumns are shared, but the deserialized nested_keys_column and nested_values_column are dropped instead of being written back to map_column. That leaves updated offsets with stale keys/values. Please assign both mutated children back to get_keys_ptr() and get_values_ptr() after deserializing them.

[github-actions]

If a struct child is shared, this mutate() clones it; elems[i]->deserialize() then writes into the clone, but the clone is discarded at the end of the loop iteration. The parent ColumnStruct continues to reference the old child. Please write child_column back to struct_column->get_column_ptr(i) after deserialization.