Document that SciToken/Validator/Enforcer handles are not thread-safe

[djw8605]

Problem

Nothing in the public header states the thread-safety contract of the API handles — and it matters more than usual here:

• Validator mutates internal state during verification (m_profile, the detected token profile).
• Enforcer stores the request being evaluated inside the handle: enforcer_test/enforcer_generate_acls write m_test_path/m_test_authz/m_gen_acls, and the scope_validator callback reads them back mid-verification.

Two threads sharing one Enforcer can therefore race so that thread A's authorization test is evaluated against thread B's requested path — a wrong authorization decision, not merely a crash. Given the library's consumers are heavily threaded (XRootD et al.), this deserves an explicit statement.

Change

Documentation only, in scitokens.h:

• Header preamble: handles are not thread-safe; one handle per thread or external serialization. Distinct handles are safe concurrently (key cache, configuration, and monitoring state are internally synchronized).
• Pointed notes on validator_create and enforcer_create, with the enforcer note explaining why (request state lives in the handle).

Making the Enforcer actually thread-safe (moving per-request state into the async status / stack) would be a larger behavioral change, best done separately if desired.

Testing

• Comment-only change; library builds cleanly.

🤖 Generated with Claude Code