Cassandra Bigtable Proxy Adapter does not return result with columns order same as Cassandra with SELECT *

**Issue:**
When querying data through the Cassandra Bigtable Proxy Adapter using a wildcard SELECT * FROM table statement, the returned column order is different from customer expected. Instead, Bigtable returns columns with a random order. This differs from native Apache Cassandra behavior, which return the primary key (row key) first, followed by the remaining columns in lexicographical order.

**Impact:**
Customers migrating from Cassandra to Bigtable whose applications rely on native Cassandra behaviour from SELECT * statements are experiencing compatibility issues. This limitation requires them to refactor their application code, slowing down the lift-and-shift migration process.

**Steps to Reproduce:**

Create a table with a specific column order in Cassandra.

Insert data into the table.

Query the table using SELECT * FROM table via the Cassandra Bigtable Proxy Adapter.

Observe that the returned column order is random (e.g. row key is not comes first)

**Expected Behavior:**
Ideally, the proxy adapter should mimic native Cassandra's behavior by having the column order with row key comes first and remaining columns lexicographically sorted when a wildcard SELECT * query is executed, minimizing the need for application code changes.

**Current Workaround:**
The only current workaround is to use explicit projections (e.g., SELECT c1, c2, c3 FROM table) to strictly dictate the result set's column order. However, this requires application-level modifications

Start by reproducing the wildcard SELECT * query through the Cassandra Bigtable Proxy Adapter and compare its result-column order with native Cassandra. Trace the adapter's result construction and column metadata handling, then verify that the row key comes first and remaining columns are lexicographically sorted without affecting explicit projections.

Written by the indexing model from the issue text.