add param type date and date-picker

[zyqzyq]

Fixes langgenius/dify#36162

tool plugin add type date and date-picker

Pull Request Checklist

Thank you for your contribution! Before submitting your PR, please make sure you have completed the following checks:

Compatibility Check

• I have checked whether this change affects the backward compatibility of the plugin declared in README.md
• I have checked whether this change affects the forward compatibility of the plugin declared in README.md
• If this change introduces a breaking change, I have discussed it with the project maintainer and specified the release version in the README.md
• I have described the compatibility impact and the corresponding version number in the PR description
• I have checked whether the plugin version is updated in the README.md

Available Checks

• just build has passed
• Relevant documentation has been updated (if necessary)

[gemini-code-assist]

Code Review

This pull request introduces DATE and DATE_PICKER parameter types to the CommonParameterType and ToolParameterType enums. Feedback indicates that these new types need to be correctly mapped to standard JSON Schema types (e.g., "string") within the LLM translation logic to prevent compatibility issues with model providers. Additionally, it is recommended to include these types in the ProviderConfig.Config enum to ensure they are available for use in provider credentials and configuration schemas.

[gemini-code-assist]

Adding DATE and DATE_PICKER to ToolParameterType without updating the translation logic in ToolSelector.to_prompt_message (lines 361-375) will cause issues with LLM tool calling. Most LLM providers (e.g., OpenAI) do not support "date" or "date-picker" as valid JSON Schema types. These should ideally be mapped to "string" (potentially with a "format": "date") when generating the schema for the LLM.

[gemini-code-assist]

The new DATE and DATE_PICKER types are added to CommonParameterType but are not included in the ProviderConfig.Config inner enum (lines 90-98). This omission prevents these types from being used in provider credentials or configuration schemas. For full consistency as a "Common" type, they should be exposed there as well.