fix: handle all supported date value types in date picker (#2956)

[JorgeEscire]

References

• Fixes Dynamic form date picker & parser may use date values unsafely #2956

Description

Replace unsafe .toString() calls on date model values with a new dateValueToString() utility that properly handles all supported types (string, Date, NgbDateStruct) and throws an informative error for unsupported object types.

Instructions for Reviewers

List of changes in this PR:

• Added dateValueToString() utility function in src/app/utils/date.util.ts that safely converts string | Date | object values to YYYY-MM-DD formatted strings
• Updated date-picker.component.ts to use dateValueToString() instead of .toString(), removing the eslint-disable comment and todo
• Updated date-field-parser.ts to use dateValueToString() instead of .toString(), removing the eslint-disable comment and todo
• Added 5 unit tests for dateValueToString() in date.util.spec.ts (string, Date, NgbDateStruct, arbitrary object, empty object)
• Added 2 test suites in date-picker.component.spec.ts to verify initialization from Date and NgbDateStruct-like objects

How to test:

1. Run npm test -- --include="src/app/utils/date.util.spec.ts" — all 32 tests should pass
2. Run npm test -- --include="src/app/shared/form/builder/ds-dynamic-form-ui/models/date-picker/date-picker.component.spec.ts" — all 17 tests should pass
3. Run npm test -- --include="src/app/shared/form/builder/parsers/date-field-parser.spec.ts" — all 3 tests should pass
4. Verify date picker fields work correctly in submission forms (e.g. Date of Issue)

Checklist

• My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using npm run lint
• My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• My PR aligns with Accessibility guidelines if it makes changes to the user interface.
• My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
• My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.