Fix #2462: counter column apiSupport reports filter:false

[erichare]

Summary

Fixes #2462.

A table with a counter column was described by the Data API with apiSupport.filter: true:

"b": {
  "type": "counter",
  "apiSupport": { "createTable": false, "insert": false, "read": true, "filter": true, "cqlDefinition": "counter" }
}

…yet filtering on that column actually fails with INVALID_FILTER_COLUMN_VALUES (there is no CQL codec that can bind a counter value into a filter). The advertised support contradicted the real behavior.

Root cause

ApiDataTypeDefs.COUNTER declared its support as Support(createTable=false, insert=false, read=true, filter=true, Update.NONE). The filter=true flag is the only source of truth for the apiSupport.filter value surfaced in listTables / listTypes / createTable describe output, so the describe output advertised a capability the runtime rejects.

Fix

Flip the COUNTER apiSupport filter flag to false so the describe output matches actual support.

This is purely a describe-output change — verified that no runtime behavior changes:

• isUnsupportedDML() (!insert() || !read() || !filter()) was already true for counter because insert=false, so the column's unsupported-DML/isUnsupportedAny() classification and ApiTableDef unsupported-columns membership are unchanged.
• The apiSupport block was already emitted (it is gated on isAnyUnsupported(), already true via createTable=false); only the inner filter field value flips true → false.
• ApiSupportDef.Matcher never gates filtering on this flag (there is no withFilter setter; all production matchers use filter=null).

read=true, filter=false is already an established, valid combination (frozen collections use it).

Tests

• Added a regression integration test listTablesReportsCounterNotFilterable to UnsupportedTypeTableIntegrationTest.Counter asserting the describe output for a counter column reports createTable=false, insert=false, read=true, filter=false.
• The pre-existing filterCounter IT already covers the runtime rejection (INVALID_FILTER_COLUMN_VALUES) and continues to pass — together they confirm describe and runtime now agree.
• Corrected the now-stale Filter(True) → Filter(False) doc comment on the Counter test class.

Test plan

• ./mvnw test-compile passes (JDK 21), formatting compliant
• CI: UnsupportedTypeTableIntegrationTest (Counter nested class) passes against DSE/HCD

[github-actions]

➡️ Unit Test Coverage Delta vs Main Branch

Metric	Value
Main Branch	52.50%
This PR	52.50%
Delta	⚪ 0.00%
ℹ️ Coverage unchanged

[github-actions]

Unit Test Coverage Report

Overall Project	52.5%	🍏

File	Coverage
ApiDataTypeDefs.java	95.8%	🍏

[github-actions]

📉 Integration Test Coverage Delta vs Main Branch (dse69-it)

Metric	Value
Main Branch	72.50%
This PR	72.50%
Delta	🔴 -0.00%
⚠️ Coverage decreased

[github-actions]

Integration Test Coverage Report (dse69-it)

Overall Project	72.5%	🍏

File	Coverage
ApiDataTypeDefs.java	99.16%	🍏

[github-actions]

📈 Integration Test Coverage Delta vs Main Branch (hcd-it)

Metric	Value
Main Branch	73.84%
This PR	73.85%
Delta	🟢 +0.00%
✅ Coverage improved!

[github-actions]

Integration Test Coverage Report (hcd-it)

Overall Project	73.85%	🍏

File	Coverage
ApiDataTypeDefs.java	99.16%	🍏

[amorton]

-1 Blocking this merging.

There are two possible fixes here: either the API support flag is wrong (we dont support it) OR we actually should support it and the bug is that we dont.

we need to decide on what we want to do before letting AI write code. Also, PR comments such as these are not very helpful it is just a mash of words

[amorton]

this is fragile and encourages copy-past coding, we would create assertion functions for this

[amorton]

There is an existing test the confirms some code things we should not be able to filter on a counter

data-api/src/test/java/io/stargate/sgv2/jsonapi/api/v1/tables/UnsupportedTypeTableIntegrationTest.java

Line 212 in 3bf486f

public final void filterCounter() {

BUT checking the design docs we said it was possible to filter on a counter.

we need to work out what is the correct behaviour

[erichare]

Good point @amorton, digging into this in more detail (i.e., whether there's a technical reason why we don't support it, and if so, can we overcome that and support it, as the spec indicates that we want to do)