ttl must work with sets incr command

[guillaume-chervet]

ttl must work with sets incr command. It seems to be not implemented. It must be for commands :

POST	/data/sets/{id}/incr	Atomically increment an integer by 1
POST	/data/sets/{id}/incrby?by={long}	Atomically increment an integer by by
POST	/data/sets/{id}/incrbyfloat?by={decimal}	Atomically increment a decimal value by by
POST	/data/sets/{id}/decr	Atomically decrement an integer by 1
POST	/data/sets/{id}/decrby?by={long}	Atomically decrement an integer by by

[guillaume-chervet]

Hi! This has been addressed in #294.

Summary of the changes made:

• Added an optional ttl query parameter, in milliseconds, to the counter endpoints: incr, incrby, incrbyfloat, decr, and decrby.
• Updated the route handlers to forward the TTL value through to the database service.
• Added validation so invalid or non-positive TTL values return 400 Bad Request.
• Preserved the existing behavior where invalid numeric values or overflow conflicts return 409 Conflict without mutating the value or TTL.
• Updated the service layer so TTL metadata is no longer dropped for non-Set mutation operations.
• Updated the SlimData interpreter so increment/decrement operations apply or override the TTL when one is provided, while leaving any existing live TTL untouched when no TTL is provided.
• Kept non-idempotent numeric mutations non-retried.
• Updated the mock database service to mirror the same TTL behavior for increment/decrement operations.
• Added test coverage for TTL application, preservation, override, invalid TTL handling, expired keys, overflow/non-numeric conflicts, and listing/filtering behavior.
• Updated documentation/data-sets.md to document the new ttl query parameter and explain the preservation/override semantics.

Thanks for reporting this and for the clear expected behavior.

---

This operation was performed by an AI via GnOuGo, the cute little bear cub just waiting to be adopted: https://github.com/GnouGo/GnouGo