[AdrianMSS]

📝 Description

Add an account context key that is separate from the user key. The account id is the stable identifier for a sign-in. It is not a DID. ContextIdKeys.User stays "user" and continues to mean the DID.

This is the framework step for trade-data issue 7, on feature/account-context-key. The api-auth half is pull request 2. Nothing in this repository writes the key. api-auth sets it after a token is verified. Node does not register it. userOrganization is already set the same way and is not registered. An empty feature list would bind the DID handler, because Is.arrayValue([]) is false, and that handler would reject the account id.

🔄 Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📚 Documentation update
• ⚡ Performance improvement
• ♻️ Code refactoring
• 📦 Dependencies update

🛠️ Changes Made

• ContextIdKeys.Account is "account", added beside UserOrganization in packages/context/src/models/contextIdKeys.ts. The exported type picks the new value up from the object. No handler is registered for it. ContextIdHelper.guard already accepts a non-empty string when a key has no handler.
• ContextIdKeys.User is unchanged.

🧪 Testing

• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have tested this change manually
• Testing not required for changes

ContextIdHelper tests check that a UUID is accepted on ContextIdKeys.Account when no handler is registered, and that an empty account id throws guard.stringEmpty. pnpm run quality passed locally.