Some troubleshooting findings:

• I'm aware of special handling of @atomic mutations in MutationFetcher.java. However, this kicks in if the number of selections (i.e. mutations is > 1) but I've reproduced this behavior even in a single mutation with @atomic and TTL.
• I've debugged Cassandra BatchMessage code too and I see the ttl value present as an attribute on the statement as seen in the screenshot. As a side note, this method returns EMPTY_RESULT regardless of whether I pass TTL or not (which also at the moment determines whether the mutation has actually been persisted).
  

Further investigation showed that in v2 all mutations with the @atomic directive insert rows with timestamp 1970-01-01T00:00:00Z if not otherwise specified in the query. TTL is computed relative to the write timestamp, so passing options:{ttl:86400} would result in a TTL timestamp of 1970-01-02.

Cassandra interprets such rows as having already expired (since they supposedly TTL'ed out back in 1970) and thus omits them from the results. I verified this in the commitlog and sstables using sstabledump. Moreover, this row would eventually expire, likely after a major compaction. Please see mutations.txt and sstabledump.txt attached.

"liveness_info" : { "tstamp" : "1970-01-01T00:00:00Z", "ttl" : 86400, "expires_at" : "1970-01-02T00:00:00Z", "expired" : true },
"cells" : [
  { "name" : "username", "value" : "2b" }
]

Root cause details

1. query.proto defines timestamp and now_in_seconds as google.protobuf.Int64Value timestamp = 4;. If this value is null invoking the generated com.google.protobuf.Int64Value getTimestamp() method returns 0. This is because it's serialized to 0 by default if it is unset.
2. In StargateGraphqlContext.java#L145-L147 the toBatchParameters method sets timestamp and nowInSeconds:

.setTimestamp(queryParameters.getTimestamp())
.setNowInSeconds(queryParameters.getNowInSeconds())

Inspecting these with a debugger shows that at runtime the timestamp field is null (screenshot) but invoking getTimestamp returns 0 as mentioned in step 1 (screenshot).

3. At the coordinator bridge level these 0 values are passed to the actual query in BatchHandler.java. This explains the write timestamp being 1970-01-01T00:00:00Z.

if (parameters.hasTimestamp()) {
  builder.defaultTimestamp(parameters.getTimestamp().getValue());
}

if (parameters.hasNowInSeconds()) {
  builder.nowInSeconds(parameters.getNowInSeconds().getValue());
}

This can be fixed by changing StargateGraphQLContext's toBatchParameters method to set timestamp and nowInSeconds only if they are non-null. This takes advantage of the generated hasTimestamp method that makes batch parameters' timestamp field behave similar to an Optional.

private BatchParameters toBatchParameters(QueryParameters queryParameters) {
  BatchParameters.Builder builder =
    BatchParameters.newBuilder()
      .setConsistency(queryParameters.getConsistency())
      // omitted a few lines
      .setSkipMetadata(queryParameters.getSkipMetadata());
  
  if (queryParameters.hasTimestamp()) {
    builder.setTimestamp(queryParameters.getTimestamp());
  }
  if (queryParameters.hasNowInSeconds()) {
    builder.setNowInSeconds(queryParameters.getNowInSeconds());
  }
  return builder.build();
}

@kathirsvn can you review/comment?

Sorry for the delay, I was out on a vacation.
This analysis for the bug sounds reasonable to me. Great find @marksurnin. It seems that the introduction of proto definitions (for the gRPC bridge) in the v2 code base introduced this bug.