Add start, end, start-ts and end-ts flags to log environment command

[FayeSGW]

This PR adds --start and --end flags (for snapshot indices and time expressions), and --start-ts and --end-ts (for timestamps) to the kosli log env command.
This is to bring the command up to date with the latest version of the API endpoint, which has these optional parameters.

[claude]

Claude finished @FayeSGW's task in 2m 18s —— View job

---

PR Review: Add start, end, start-ts and end-ts flags to log environment command

• Run static analysis (build, vet, mod tidy)
• Read and review changed files
• Post review feedback

---

Static Analysis

All checks pass:

• go build ./... — clean
• go vet ./... — clean
• go mod tidy — no diff

Review Summary

This is a clean, well-structured PR that follows existing codebase patterns closely. The changes add four new query parameters to the log environment command by extending the options struct, registering Cobra flags, and conditionally appending them to the API request URL — exactly mirroring how --repo and --interval are already handled.

What's good:

• Flag descriptions are clear and include the unit ("in seconds") for the timestamp flags — nice follow-up in the second commit.
• The examples in logEnvironmentExample cover the three main use cases (snapshot index, time expression, Unix timestamp), which will show up in --help output.
• Test cases cover the key permutations: start-only, end-only, both as time expressions, both as timestamps, and float timestamps.
• Using float64 for timestamps is a pragmatic choice that handles both integer and sub-second precision.
• strconv.FormatFloat with 'f' format and -1 precision preserves full fidelity for the API.

Minor observations (non-blocking):

1. Zero-value sentinel for timestamps — Using != 0 means epoch 0 can't be represented. As noted in the earlier review thread, this is fine for a delivery tool. Acknowledged.

2. No client-side flag conflict validation — --start/--end + --start-ts/--end-ts or --interval + any of these could be combined. The author confirmed the API handles conflicts, which is a reasonable approach — it avoids duplicating validation logic that could drift out of sync.

3. Test assertions — The new tests verify commands don't error but don't assert on output (no golden/goldenRegex). The author noted filtering is tested server-side, which is fair for pass-through query parameters. The existing pattern in this file is mixed — some tests have golden assertions, some don't.

Verdict: This PR is ready to merge. It's a straightforward, well-scoped vertical slice that adds optional API parameters with appropriate tests.