feat(access): let an assistant in for up to a year where the box takes it

[frahlg]

Problem

Fredrik, 17 October 2026: an assistant's access should be able to last longer than 30 days, up to a year. srcfl/ftw#1686 raises the box's limit and FTW Cloud's offer now asks for a year (srcfl/ftw-cloud#27). An app must not offer a year to a box that refuses it: an old box answers E_CAP_EXCEEDED; it does not cut the length short.

Change

• Choices (Face ID approval and renew): 1, 7, 30 and 90 days and a year for an assistant. Sourceful stays at 1, 3, 7 and 14 days. A year reads "1 year" / "1 år".
• An offer starts at 30 days (a week for Sourceful). Before, it started at the longest choice, which would now be a year.
• The box decides the most. AgentList reads longestMs from agent.list. AccessModel.boxLongestMs(role) gives it only once the box has answered this visit; a cached list never counts. Grant.lengths, Grant.from, OfferFlow.lengths(boxMs:) and the renew picker cap at the least of the role's limit, the offer's ttlS and the box's word.
• A box that says nothing takes 30 days (AccessWire.unstatedLongestMs). A newer app on an older box offers 30 days at most, though the offer asks for a year.
• The demo box sends longestMs like a newer box, or none like an older one (SimulatedAccess.longestMs = nil), and checks the length on renew as well as on add.

Apps already out (up to 0.4.7) cap at their own 30 days, so they never send a box more than it takes either.

• The offer page reads the box. A link (iPhone: a consent link or QR code goes straight to review, no code to type #84) opens the offer page with nothing else having read agent.list, so boxLongestMs stayed nil and the picker and the grant stayed at 30 days. The page now reads the list when it appears, which also lets the "already has access" check in AccessModel.approve see the box's rows. OfferFlow.approve reads it first if the page has not, so a length chosen before the list arrived is not cut.
• A far end shows its year. "Until" and "Ends" add the year when the end is in another calendar year or more than about five months off, so a year granted on 17 Oct no longer reads "Until 17 Oct".

Order. Renewing offers a year from the box's longestMs alone. With an FTW Cloud older than srcfl/ftw-cloud#27, a grant renewed for a year still loses its assistant 30 days after the code swap. Ship this after #27 is deployed.

Tests

• aYearOnlyWhereTheBoxSaysItTakesOne, anOfferStartsAt30Days, theBoxSaysHowLongItTakes (OfferTests).
• aLinkToABoxThatTakesAYearOffersAYear and approvingReadsTheBoxFirst (AccessFlowTests): a link to a box that takes a year offers a year once the page has read the list, and grants it; a year chosen before the list arrived is kept. The second fails without the read in approve.
• aFarEndShowsItsYear (OfferTests): a year out reads "Until 17 Oct 2027"; 30 days out has no year; another calendar year, or more than five months off, has one.
• aBoxThatTakesAYearIsOfferedAYear and anOlderBoxIsOfferedNoMoreThan30Days (AccessFlowTests, against the demo box): the old box gets 30 days and the grant goes through; a year sent anyway is refused.
• swift test in appleApp/FTWKit (rebased on main with iPhone: a consent link or QR code goes straight to review, no code to type #84): 511 and 257 tests pass. The app builds for the iOS Simulator (xcodebuild build).
• Not seen in the simulator: CoreSimulator on this Mac is older than the Xcode build ("Current version (1171.7.0) is older than build version (1174.9.2)"), so no simulator runs here. The only visible change is the extra items in two pickers and the 30-day start; the Apple workflow photographs the demo.

Pairs

• feat(agents): an assistant's grant may last a year, and agent.list says so ftw#1686: AgentMaxMs a year, longestMs in agent.list and on the box page.
• feat(oauth): an assistant's tokens may last as long as its grant, up to a year ftw-cloud#27: the offer asks for a year; refresh tokens follow the grant.
• privacy: what FTW Cloud sees and keeps when an assistant has access ftw-web#21: the privacy page says access lasts up to a year.
• No registry change: ftw-webapp/contract/registry.yaml holds no copy of the number, and agent.list's fields live in srcfl/ftw's docs/agents.md.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-17T06:39:02.608364Z	6f52d83	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6f52d83c1a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Refresh box limits before capping the offer

When a consent link opens directly from RootView before Settings/Access has been visited, keysKnown is still false because OfferFlowView starts the offer without calling access.refresh(). Consequently boxLongestMs returns nil here, which is interpreted as an old box's 30-day limit, so the picker hides the 90-day and one-year choices even for a capable box. Approval also constructs the capped grant before AccessModel.signed performs its refresh, so the direct-link flow cannot grant more than 30 days; load agent.list before rendering or approving the offer.

Useful? React with 👍 / 👎.