Add THREAT_MODEL.md + SECURITY.md and wire AGENTS.md (security-model discoverability)

[potiuk]

Adds a draft THREAT_MODEL.md for Apache TinkerPop, a SECURITY.md pointing to it, and a ## Security section in AGENTS.md, so automated security scanners (and researchers) can mechanically discover the project's threat model via the AGENTS.md -> SECURITY.md -> THREAT_MODEL.md chain.

The threat model is a v0 draft authored by the ASF Security team for the PMC to own and refine. It follows a standard rubric (scope, trust boundaries, adversary model, security properties provided / not provided, downstream responsibilities, known non-findings, triage dispositions). Every claim carries a provenance tag — *(documented)* / *(inferred)* / *(maintainer)* — and every *(inferred)* claim routes to a numbered question in §14 for the PMC to confirm, correct, or strike. The highest-value items to confirm: the default authentication/TLS posture, the script-execution disposition (string scripts run through the Groovy engine), and the Gryo/serialization handling.

THREAT_MODEL.md and SECURITY.md carry the ASF license header; AGENTS.md is RAT-excluded. No code or behaviour changes — documentation only.

This is a proposal for the PMC to review — please adjust, correct, or reject as needed.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.28%. Comparing base (a28cd1f) to head (e946af0).
⚠️ Report is 22 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #3449      +/-   ##
============================================
- Coverage     76.35%   76.28%   -0.08%     
- Complexity    13424    13520      +96     
============================================
  Files          1012     1017       +5     
  Lines         60341    60927     +586     
  Branches       7075     7136      +61     
============================================
+ Hits          46076    46478     +402     
- Misses        11548    11648     +100     
- Partials       2717     2801      +84     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Cole-Greer]

I don't think we want or need to maintain a list of (active) maintainers here.

Suggested change

	`3.8-dev` *(maintainer — colegreer, scope confirmation)*. The model focuses on the network-facing and
	`3.8-dev`. The model focuses on the network-facing and

[Cole-Greer]

It's clear we will need to split this model into 2 very distinct versions for 3.7/3.8 and 4. As this PR is already targeting master, I suggest we focus this one on 4. I'll open a twin PR which cherry-picks the draft back to 3.7, and we can iterate on the websocket/bytecode model there.

[potiuk]

Thanks @Cole-Greer — both well taken.

Maintainers list (L27) — agreed, dropping it; applying your suggestion.

3.7/3.8 vs 4 split (L47) — that makes sense, and I'll defer to you on the structure: I'll refocus this PR on the 4 / master line as you suggest. If you're up for opening the twin PR cherry-picking the 3.7/3.8-appropriate version, that's the cleanest split — say the word and I'll keep the shared wording aligned so the two don't diverge. Whatever fits your release lines best.

Thanks for the careful read.

[potiuk]

@Cole-Greer — confirming I'm holding this PR rather than pushing a partial refocus. The 3.7/3.8-vs-4 split is yours to drive via the twin PR you mentioned; once that's open (or you tell me which way you'd like the version scope to land), I'll refocus this one on 4/master and keep the shared wording aligned with yours. The maintainers-list reword you suggested folds in at the same time. Nothing needed from you until then.