docs: add security policy

[JasonXuDeveloper]

Summary

• Add SECURITY.md file to establish security policies for the project
• Only JEngine 1.x versions are supported from 2026 onwards
• Provides clear vulnerability reporting guidelines

What's Included

Supported Versions

Version	Supported
1.x	Yes
< 1.0	No

Vulnerability Reporting

• GitHub Security Advisories (preferred method)
• Email to jason@xgamedev.net
• Guidelines on what information to include
• Expected response timelines

Security Best Practices

• Encryption recommendations (AES/ChaCha20 for production)
• Code signing guidance
• Network security tips
• Dependency security notes

Why This Matters

GitHub uses SECURITY.md to:

• Display security policy in the repository's Security tab
• Guide security researchers on proper disclosure
• Show users which versions receive security updates

Test plan

• Review SECURITY.md content for accuracy
• Verify email address is correct
• Check that Security tab shows the policy after merge

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR adds a comprehensive SECURITY.md file to establish security policies and reporting procedures for the JEngine project. The document provides clear guidelines for vulnerability disclosure, supported versions, and security best practices.

Changes:

• Added SECURITY.md with supported version policy (1.x only)
• Established vulnerability reporting procedures via GitHub Security Advisories and email
• Documented security best practices for encryption, code signing, and network security

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The date entry "January 2026" is potentially problematic. The current date is January 25, 2026, so if this security policy is being established now, the date should be more specific (e.g., "January 25, 2026" or just "January 2026" is acceptable if intentionally kept vague). However, if version 1.0.0 was released in September 2025 (as stated in line 5), the security policy should reflect when it was actually established, not a future or approximate date.

Suggested change

	| January 2026 | 1.0.0+ | Initial security policy established |
	| September 2025 | 1.0.0+ | Initial security policy established |