fix(adt): CSRF HEAD→GET fallback + secure-cookie fix + SAP_SESSION_TYPE env var

[frd1201]

Relates to #88. Closes #104.

Summary

Three related fixes for systems where vsp write operations fail with CSRF or lock-handle errors. All three were reproduced and verified on a real on-premise SAP S/4HANA system accessed through an nginx reverse proxy over plain HTTP.

1. CSRF token: HEAD→GET fallback — closes #104

fetchCSRFToken() uses HEAD for performance. On systems where CL_ADT_WB_RES_APP does not implement HEAD (returns 400 or 403 without a token in the response headers), vsp fails with "no CSRF token in response" or "access forbidden (403)" for all write operations.

Fix: if HEAD returns no usable token, automatically retry with GET — which is what Eclipse ADT uses. HEAD is still attempted first; the fallback only fires when needed, so systems where HEAD works are unaffected (~0 ms overhead).

Diagnostic used to confirm:

# HEAD → 400, no token
curl -sk -o /dev/null -w "%{http_code}" -X HEAD -u USER:PASS \
  -H "X-CSRF-Token: Fetch" "http://host:1440/sap/bc/adt/core/discovery?sap-client=090"
# → 400

# GET → 200 + token (same as Eclipse ADT)
curl -sk -D - -o /dev/null -X GET -u USER:PASS \
  -H "X-CSRF-Token: Fetch" "http://host:1440/sap/bc/adt/core/discovery?sap-client=090" \
  | grep x-csrf-token
# → x-csrf-token: Pa_4WUq0iJFTXv2SbFiWeQ==

Also fixes a double-defer bug in the previous fallback implementation (both defers pointed to the GET body after resp was reassigned).

2. Secure-cookie stripping for HTTP reverse proxies

SAP systems behind nginx or other HTTP proxies often set session cookies (SAP_SESSIONID_*) with the Secure flag. Go's standard cookiejar refuses to send Secure cookies over plain HTTP, so the session cookie is never sent back on subsequent requests — the CSRF token appears "abgelaufen" (expired) because SAP can't locate the session.

Fix: httpCookieJar wraps cookiejar.Jar and strips the Secure flag when storing cookies received over HTTP. Outgoing HTTPS requests are unaffected.

Observed response from the affected system:

set-cookie: SAP_SESSIONID_D18_090=...; path=/; secure   ← Go drops this over HTTP
x-csrf-token: Pa_4WUq0iJFTXv2SbFiWeQ==

3. SAP_SESSION_TYPE env var — relates to #88

Exposes adt.SessionType via the SAP_SESSION_TYPE environment variable (stateful | stateless | keep). Setting stateful causes vsp to send X-sap-adt-sessiontype: stateful on every request, which keeps the SAP session alive across the Lock→Write sequence on systems that require it.

Invalid values emit a clear warning to stderr instead of silently falling back.

SAP_SESSION_TYPE=stateful

Note: the upstream commit 22517d4 already pins stateful on individual write paths. This env var is complementary — it provides a system-wide override for operators who need all requests to be stateful without patching individual call sites.

[txape10]

Found a bug when applying this PR: the HEAD→GET CSRF fallback fires on any
empty token header, including 401/403 responses where the token is absent
because credentials are invalid — not because HEAD is unsupported.

This breaks TestTransport_Request_RetryOn401_ReauthFails ("Expected 2
requests, got 3") because the extra GET consumes a mock slot.

Fix — guard the fallback against auth failures:

headIsAuthFailure := headResp.StatusCode == http.StatusUnauthorized ||
                     headResp.StatusCode == http.StatusForbidden
if (headToken == "" || headToken == "Required") && !headIsAuthFailure {
    // GET fallback
}
On 401/403 retrying with GET won't help — the credentials are wrong, not
the HTTP method. This keeps the original test passing and avoids an
unnecessary round-trip on auth failures.

[frd1201]

Thanks @txape10 — fixed exactly as you suggested. The HEAD→GET CSRF fallback in fetchCSRFToken now skips 401/403 (auth failures), so it only retries with GET when HEAD genuinely returns no token for a non-auth reason. TestTransport_Request_RetryOn401_ReauthFails is back to passing (2 requests, no extra round-trip on bad credentials). Pushed — would appreciate another look!