fix: preserve chatflow id on API create

[puneetdixit200]

Summary

• Preserve an explicit chatflow id when creating a chatflow through the API, so exported flows can be restored with their original ID.
• Validate caller-provided IDs and reject duplicates before saving, avoiding accidental updates through the create path.
• Add controller and service coverage for the create-ID path.

Fixes #6418

Testing

• npx --yes pnpm@10.26.0 --filter flowise-components build
• npx --yes pnpm@10.26.0 --dir packages/server exec jest src/controllers/chatflows/index.test.ts --runInBand
• npx --yes pnpm@10.26.0 --dir packages/server exec jest src/services/chatflows/index.test.ts --runInBand
• npx --yes pnpm@10.26.0 exec prettier --check packages/server/src/controllers/chatflows/index.ts packages/server/src/controllers/chatflows/index.test.ts packages/server/src/services/chatflows/index.ts packages/server/src/services/chatflows/index.test.ts
• npx --yes pnpm@10.26.0 exec eslint packages/server/src/controllers/chatflows/index.ts packages/server/src/controllers/chatflows/index.test.ts packages/server/src/services/chatflows/index.ts packages/server/src/services/chatflows/index.test.ts
• git diff --check

[gemini-code-assist]

Code Review

This pull request enables the preservation of caller-provided IDs during chatflow creation, which is necessary for importing flows. It introduces validation logic to ensure that provided IDs are valid UUIDs and do not conflict with existing records, along with comprehensive unit tests for both the controller and service layers. Review feedback identifies that using Object.prototype.hasOwnProperty.call on a class instance may be unreliable due to TypeScript property initialization behavior and suggests using a nullish check instead.

[gemini-code-assist]

Using Object.prototype.hasOwnProperty.call on a class instance like newChatFlow (which is an instance of the ChatFlow entity) can be unreliable. Depending on the TypeScript configuration (specifically useDefineForClassFields), class properties might be initialized to undefined in the constructor, which would cause hasOwnProperty to return true even if the property wasn't explicitly provided by the caller. This would lead to a BAD_REQUEST error on every chatflow creation where an ID is not provided. A safer and more idiomatic approach is to use a nullish check.

Suggested change

	if (Object.prototype.hasOwnProperty.call(newChatFlow, 'id')) {
	if (newChatFlow.id != null) {

References

1. In JavaScript/TypeScript, use loose equality (== null) as a standard idiom for a 'nullish' check that covers both null and undefined.