[michalantoszczuk]

What does this PR do?

Fixes #1348.

When someone fills in yesterday's timesheet the following morning, selecting a 09:00 start and then entering 8h currently overwrites the start by subtracting from the end. Manual creation now preserves the selected start and calculates a 17:00 end on the intended day. This avoids recording incorrect working hours while the total duration appears correct.

The shared duration input gains an optional fixed endpoint, passed through TimeRangeFields. Only TimeEntryCreateModal opts into preserving the start; the other consumers retain their existing behavior.

The linked issue also describes a possible Keep start fixed / Keep end fixed UI control. This patch implements the smaller change to manual creation without adding that control.

Validation

• npm run test:unit: 214 tests passed across 18 files, including 8 new regression cases.
• Coverage includes yesterday at 09:00 plus 8h, with and without selecting the end date, submitted timestamps, midnight, daylight saving transitions, and the existing default of preserving the end.
• ESLint and Prettier passed for the changed files; ESLint reports one existing warning about the modal's show model type.
• npm run type-check is blocked by the missing local Composer dependency vendor/tightenco/ziggy in resources/js/app.ts; no errors remain in the changed files.

Checklist (DO NOT REMOVE)

• I read the contributing guide
• I signed the Contributor License Agreement.
• I commented my code, particularly in hard-to-understand areas

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}