Make HTTP client timeout configurable via existing -t/--timeout flag

[hb-andy]

Problem

The HTTP client used internally in api/client.go had a hardcoded timeout
of 5 seconds (DefaultTimeout = 5), completely independent of the
-t/--timeout flag exposed via the go-check library (defaults to 30s).

As soon as a request to the SentinelOne API takes longer than 5 seconds,
the check fails with:

HTTP request failed: Get "...": context deadline exceeded
(Client.Timeout exceeded while awaiting headers)

...no matter what value is passed via -t. We ran into this in
production: our SentinelOne threats query started taking ~11-12s to
respond (confirmed independently via curl, which succeeded fine), while
the plugin kept failing every single time, since 11s > the hardcoded 5s.

Fix

• api.NewClient() now takes an explicit timeout time.Duration
  parameter instead of relying on the hardcoded constant.
• Config (in check.go) gets a Timeout time.Duration field, passed
  through to api.NewClient().
• main.go sets config.Timeout from plugin.Timeout (the existing
  -t/--timeout flag) after parsing arguments.
• DefaultTimeout (5s) is kept as-is and only used as a fallback if
  NewClient is called with a zero/negative duration.

This is a minimal, behavior-preserving change: the effective default
timeout stays the same (30s from the existing flag default), but it's
now actually possible to tune it.

Testing

Verified locally against a real SentinelOne instance:

• Without -t: succeeds (falls back to the default 30s, comfortably
  above the ~11s the API currently needs to respond).
• With -t 1: fails fast with a timeout error, confirming the flag now
  actually controls the HTTP client timeout.

[martialblog]

Hi, thanks for the PR. Looks good, but you probably need to update the test cases as well.

[hb-andy]

Hi. Good catch, thanks! Updated api/client_test.go to match the new NewClient signature. go test ./... passes locally now.

[martialblog]

Thanks for the contribution. I'll try to create a new release soon.