Rework task 3 of the split-bill project after the review (the first return). The changes lie uncommitted in the working copy, this is your previous attempt, continue from it. Read the project rules, do not commit. At the end run the formatting and make check, it must be green.
The task and the criteria are the same: the bill in the page address without a server, a broken or old link does not break the page, but shows a clear message. Do not break the other criteria and the existing tests.
The review remarks and the lead's decisions.
First, serious: a forged link crashes the page. The amounts are safe integers separately, but the total loses precision when added, and the transfer calculation throws an exception before the fragment-change handler is attached. The lead's decision: the rule "the sum of all expenses is a safe integer" lives in one place in the bill logic, for example a separate check based on the total of the expenses, the limit is a named constant equal to the maximum safe integer, with a comment on why: with a larger sum the balances lose precision. The rule is used in two places. The link parsing rejects such a bill as invalid, with tests for the pair of amounts from the example and for the example itself: the page shows the message about a corrupted link, does not crash, the fragment change works. The expense form does not add an expense after which the total would exceed the limit and shows a short clear message about too large an amount, with a test. This closes the same hole in the form that existed before the task.
Second, medium: the ban on DOM globals for the bill logic, the calculations and the new directory is incomplete. Add history, self, globalThis, sessionStorage and fetch. Make sure the code in these directories does not use globalThis legitimately, and check in a copy that the linter fails on each of them.
Third, medium: the race in "Share". A late clipboard answer after a change of the bill writes "Link copied" over the reset message, and a late refusal shows the field with an outdated link. Fix it now: an answer that came after the redraw of the section is ignored. A test: press "Share", change the bill before the answer, then resolve or reject the promise — neither the message nor the field appears.
Fourth, medium: a name of 40,000 characters gives a code longer than the limit, after a reload the link is considered corrupted and the data is lost. The lead's decision: limit the participant name length with the constant 40, add the name problem variant "too long" to both name checks, the length is counted after trim in the characters that a person sees; the text in the form is "Name is longer than 40 characters — shorten it" with the number from the constant; the link parsing applies the same rule as an invalid bill. The remaining theoretical limit, when hundreds of participants or thousands of expenses give a code longer than the limit, is a deliberate limitation: describe it in one phrase in the comment at the code length limit constant. Tests: in the bill logic, in the parsing (a name of 41 characters is an error; 40 characters of Cyrillic and emoji — a round trip) and the form message.
Fifth, medium: "Link copied" is red. Fix it now: the success message gets its own neutral or green style, the errors stay red.
Sixth, small: rename data and parseData to payload, encodedPayload and parsePayload. Seventh: name the condition of the clipboard being present isClipboardAvailable. Eighth: make the multiline if with braces.
In the answer write what changed for each remark, disagreements with the reason and the result of the checks.