MINOR: Fix Typos in Documentation for Grouped Aggregations and Cache Locality (#46793)

**Description:**  
This pull request corrects minor typos in the documentation files:
- In `docs/source/cpp/compute.rst`, the word "invokable" is now spelled correctly.
- In `docs/source/developers/cpp/acero.rst`, the word "initially" is now spelled correctly.

These changes improve the clarity and professionalism of the documentation without affecting any code functionality.

Authored-by: kilavvy <[email protected]>
Signed-off-by: Nic Crane <[email protected]>

Author: kilavvy

docs/source/cpp/compute.rst

@@ -315,7 +315,7 @@ the input to a single output value.
 Grouped Aggregations ("group by")
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Grouped aggregations are not directly invokable, but are used as part of a
+Grouped aggregations are not directly invocable, but are used as part of a
 SQL-style "group by" operation. Like scalar aggregations, grouped aggregations
 reduce multiple input values to a single output value. Instead of aggregating
 all values of the input, however, grouped aggregations partition the input

docs/source/developers/cpp/acero.rst

@@ -328,7 +328,7 @@ this leads to problems with cache locality.  For example, let's assume we have a
 exec nodes, scan, project, and then filter (this is a very common use case).  Now let's assume there are 100 batches.
 In a task-per-operator model we would have tasks like "Scan Batch 5", "Project Batch 5", and "Filter Batch 5".  Each
 of those tasks is potentially going to access the same data.  For example, maybe the ``project`` and ``filter`` nodes need
-to read the same column.  A column which is intially created in a decode phase of the ``scan`` node.  To maximize cache
+to read the same column.  A column which is initially created in a decode phase of the ``scan`` node.  To maximize cache
 utilization we would need to carefully schedule our tasks to ensure that all three of those tasks are run consecutively
 and assigned to the same CPU core.