Frontend: Build Inactivity Grace Period Custom Duration Picker

[ONEONUORA]

📌 Target Component

frontend/components/plans/CreateInheritancePlanPanel.tsx

📝 Description

Grace period picker only allows fixed preset dropdowns (30, 90, 180 days) without custom day input or seconds conversion preview.

📋 Implementation Requirements

1. Add custom integer input for grace period in days.
2. Show exact human-readable date preview when plan would expire if unpinged today.

🎯 Testnet Goal

Flexible inactivity plan creation on testnet.

[bilhokista]

I have opened #1213 for this issue.

First, a correction to the premise. The issue says the picker "only allows fixed preset dropdowns (30, 90, 180 days) without custom day input", but on master it is the opposite — there is no dropdown at all, just a free <input type="number">. So requirement 1 was already met, and the presets the issue assumed existed did not. I added them anyway as one-click shortcuts beside the free input rather than replacing it, since the issue clearly expects them to be available; easy to drop if you would rather keep the field bare.

What I found instead was a bug. The input fed its raw value straight through: setInactivityDays(Number(e.target.value)), then grace_period: inactivityDays * 86400. Number("") is 0, so clearing the field produced a plan with a zero-second grace period — one that triggers inheritance immediately — and Number("abc") is NaN, producing NaN seconds. The min={1} max={3650} attributes do not prevent this: they constrain the spinner arrows and native form validation, not typing or pasting, and this form does not use native validation. The clamp now happens in code, with a single daysToSeconds path to the contract value.

The field is also backed by separate text state so it can be empty while you are mid-edit without the value snapping to 1 under your cursor, settling on blur.

For the preview, two details worth mentioning: dates are built by adding whole days rather than milliseconds so "180 days from now" does not drift by an hour across a daylight-saving boundary, and the month is spelled out because 03/12/2027 means two different days depending on the reader — and this date is the entire point of the control. The sentence always describes the clamped value, so it cannot claim a duration the plan will not use.

One thing worth flagging: while writing the tests, clampInactivityDays(Infinity) returned the minimum, because the guard was !Number.isFinite(value) which lumps ±Infinity in with NaN. "Impossibly large" mapping to "one day" is the opposite of intent. I fixed the implementation rather than relaxing the test, and left a comment at that line explaining why the guard is narrower than it looks like it should be.

On verification: the new test file (19 cases) runs in CI since this frontend has Vitest configured. I could not execute it locally, so I also ran the module standalone against 30 assertions, all passing. The panel wiring itself needs CI or a manual check.

Also a heads-up: this touches the same component as my open PR #1212, in a different section. Whichever lands second may want a trivial rebase and I am glad to do it.