Add an API-Version response header and a documented deprecation policy for /api/v1 routes mounted in src/index.ts

[Jagadeeshftw]

Description

Every router in src/index.ts is mounted flatly under /api/v1 with no machine-readable version signal in the response, so clients cannot detect a future /api/v2 migration programmatically. Add an API-Version: 1 response header applied globally to /api/v1/* and document the versioning/deprecation contract the team intends to follow (sunset headers, minimum notice period).

Requirements and context

• Add middleware in src/index.ts that sets API-Version on every response under /api/v1
• Read the version from a single constant so it is trivial to bump when v2 ships
• Document the deprecation policy (how a future version is announced, minimum support window) in a new doc file
• Must be secure, tested, and documented
• Should be efficient and easy to review

Suggested execution

Fork the repo and create a branch

git checkout -b feature/api-version-header

Implement changes

• Update/Write: src/index.ts
• Add/Update tests: src/index.test.ts
• Add documentation: docs/api-versioning.md
• Include clear code comments and TS types
• Validate security assumptions

Test and commit

• Run tests: pnpm test
• Cover edge cases
• Include test output and security notes

Example commit message

feat: add API-Version response header

Guidelines

• Minimum 95 percent test coverage
• Clear documentation
• Timeframe: 96 hours

[temisan0x]

Hi Maintainer,

I’m a smart contract and full-stack developer interested in contributing to this issue. I have hands-on experience with Rust, Soroban, TypeScript, and blockchain development, and I’ve contributed to projects with a strong focus on writing clean, secure, and maintainable code.

Given the scope of this issue, I’m confident I can deliver a complete solution within 24 hours of assignment.

I’d appreciate the opportunity to contribute and help move this issue forward.