settings: show the exact next-charge timestamp

[ClaydeCode]

Closes #56.

The Subscription card's active state rendered subscription.next_billing_date through the formatDateHumanize filter, so a paying subscriber read "Next charge in a month." It now reads "Next charge: 2026-07-01."

Per the comment on the issue, this is not a polish item: with a paid subscription the length of the current term and the date of the next charge have to be unambiguous, and a humanised interval is what creates the UWG exposure. The Next charge: wording is what freeshard-controller/docs/superpowers/specs/2026-04-24-paypal-billing-design.md specifies for the Active state.

What changed

• src/views/Settings.vue — the next-charge line uses formatDate instead of formatDateHumanize.
• src/lib/dates.js (new) — formatDate(value), the body of the existing formatDate filter, extracted so the unit suite can reach it. Same extraction pattern as src/lib/pricing.js.
• src/main.js — the formatDate filter is registered from that function.
• src/components/TextField.vue — one optional tooltip prop, for the hover described below.
• tests/unit/dates.spec.js (new) — two cases on the formatter.

The date carries no clock time

The first version of this PR rendered 2026-07-01 13:30. Only the day matters for a charge, so the time is gone. That also disposes of a trap in the filter being reused: it formatted with hh, a 12-hour clock with no meridiem, which renders 13:30 as 01:30. With no clock component there is nothing left to be ambiguous about. The filter had no call sites before this PR, so nothing else on screen moved.

The other seven dates now show the exact date on hover

The card states seven further dates as intervals: delete_after in the trial and grace states, last_payment_failed_at, ended, the backup passphrase access time, and time_created / time_assigned / delete_after in the About overlay. None of them is a charge falling due, so none carries the billing-transparency requirement that motivates the change above, and they keep reading as intervals, which is the right default for "3 days ago".

But an interval is the wrong thing to read when the question is which day something happens, so hovering any of them now shows the calendar date. bootstrap-vue is already a dependency and b-tooltip is already used in Navbar.vue, so this is the v-b-tooltip directive and nothing new. The three About-overlay fields go through TextField, which takes its content as a string and had nowhere to hang a title, so it gained one optional tooltip prop; it is used only by this view and the prop is inert when absent.

Test evidence

The suite is a pure-unit one (tests/unit/, no @vue/test-utils in the repo), so the tests cover the formatter, not the template. The formatter test was broken on purpose to check it has teeth: putting HH:mm back into the format string fails both cases, 2 failed / 28 passed. Restored, 30 pass across 4 suites.

npx vue-cli-service lint is clean, and npm run build completes, which is what compiles the templates the tooltips were added to. Locally the build needs NODE_OPTIONS=--openssl-legacy-provider on Node 24; the serve script already carries that flag and build does not, which is a pre-existing wrinkle this PR does not touch.

Note on the issue body

The issue quotes next_charge_at at Settings.vue:70. On current main the field is subscription.next_billing_date and the line is 92 — the card was reworked after the issue was filed. The bug the issue describes is the same one; only the field name moved.