[aicayzer]

Summary

Adds a This Marfa page to Settings, so a person can see and change the connected Marfa server's own settings without its web console: its name, how long deleted items stay, and how long it keeps item versions. It is a page of its own rather than part of Library, because these settings belong to the server and not to this Mac's copy, and they have their own draft, save and failure states.

Changes

• A new Settings page, This Marfa, after Library. Its fields are the server name, deleted-item retention, the three version windows and the most versions kept per item. Each is an inline text field checked against the contract (digits, range, name length and hidden characters) before anything is sent. An empty field removes the setting so the server's default applies, and the page says what that default is.
• Edits are a draft. Save sends one PATCH /config with only the changed fields; Revert drops the draft. The page then shows what the server answered.
• A change that keeps things for less time (shorter deleted-item retention, shorter version windows, fewer versions) first asks in a native confirmation dialog what may be removed for good.
• Before sending, a save reads the settings again. If a setting it would change has moved on the server, nothing is sent; the page shows the new value and keeps what was typed.
• A server that cannot be reached, a refused value and an unreadable key keep the draft and say why. A key without config.manage gets an unavailable page with an Open in Browser button.
• MarfaServerConfig calls the Swift SDK client behind a small InstanceConfigSource seam, injected through the host like Version History.
• Left out on purpose: enforcement levers, enrichment, OCR, error-reporting and heartbeat switches, audit, event-log and inbound retention, and unused-app retirement.

Testing

• Unit plan, run once in full: succeeded. New unit tests use a fake config source and cover the patch holding only changed fields, an emptied field, contract checks, the confirmation for shorter retention, a setting changed elsewhere, a 403, an unreachable server and a refused value keeping the draft, a changed server, and the request body and error mapping. A mutation that made a save send every field made two of them fail.
• One live test against the demo test instance: reads the settings, renames the server, checks nothing else changed, and puts the name back. It passed with the admin key; the MAPP key lacks config.manage and got the 403, which showed the unavailable path against a real server. No retention was changed on any live instance.
• Not tested: the page itself. No window was opened and the UI plan was not run, so the layout, wording as drawn, the confirmation dialog and the Settings page list are unseen. The String Catalog keys were appended by hand.

Notes for reviewers

• The server's answer carries no effective values, and a key cannot read the server's environment. An unset field therefore shows the documented default and says whoever runs the server may have set another, and "shorter" is judged against that shown value.
• Version window order is checked in the app only when both windows are typed; otherwise the server judges it and its reason is shown.
• Open pull requests feat(marfa): sign in through the browser instead of pasting a key #98 and feat(editor): show pictures through marfa's embed bindings #127 also touch MarfaHost, Libraries and the String Catalog, so whichever merges second may need a rebase.
• The sidebar-foot and UI test lists of Settings pages are updated; the UI test edit was not run.

Checklist

• The title is a scoped Conventional Commit.
• New behavior has a test that was seen failing first, or no test was needed and the reason is above.
• Docs, comments and the contract still say what is true after this change.