jumpcloud: fix start_time errors when source_lag_time is configured

[kcreddy]

Proposed commit message

jumpcloud: fix start_time errors when source_lag_time is configured

PR #15432 (v1.17.0) added source_lag_time with a guard condition to
clamp start_time when the cursor is ahead of now - source_lag_time.
Two bugs in the implementation cause 400 Bad Request errors from the
JumpCloud API:

1. parseDate uses the default RFC3339 layout, which cannot parse
   JumpCloud's fractional-second timestamps (e.g.
   2023-01-14T08:16:06.495Z). When parsing fails, parseDate silently
   returns zero time, disabling the guard condition entirely.

2. The YAML >- block scalar introduces a trailing newline in the
   if-true branch output. When the guard fires, start_time is sent
   as "2026-03-09T10:46:26Z\n", which JumpCloud rejects as invalid.

Fix (1) by passing "RFC3339Nano" layout to parseDate so it handles
fractional seconds. Fix (2) by adding the -]] trim marker to strip
the trailing newline.

Exercise the source_lag_time code path in the existing system test.

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices

[elasticmachine]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[efd6]

nit only.

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 3009c86

History

• 💚 Build #40943 succeeded 1430dba
• 💔 Build #40934 failed f3c2204

cc @kcreddy

[elastic-vault-github-plugin-prod]

Package jumpcloud - 1.17.1 containing this change is available at https://epr.elastic.co/package/jumpcloud/1.17.1/