2.3.0

Changed: the event detail screen is the form

The screen used to be read-only. Type, status, visibility, timezone, slug and description sat in a
grey card as key/value pills, and an "Edit" button led to a second screen carrying the same
blueprint. A collection entry has no such break: what is on the screen is the field, and Save sits
top right. This screen now works the same way — same blueprint, same PATCH /cp/events/{event},
core's own PublishContainer and tabs, with the sidebar coming from the blueprint's sidebar tab.

GET /cp/events/{event}/edit is gone with it, and so is the "Edit" row action on the events
listing: it would have been the same link as "View" under a second name. Anything linking to the
edit URL should link to the event's own screen.

The calendar feed URL keeps a panel of its own below the dates. It is not a field of the event — it
belongs to the installation — and it is the only place in the Control Panel that shows it.

Changed: dates are edited in a stack, not on a page of their own

"Add date" and "Edit" on a single date opened a separate screen and navigated away
from the event. Both now open a stack over the event. The two routes are unchanged and still answer
an ordinary request; the stack asks them for JSON, which is what Statamic\CP\PublishForm hands its
own Vue page. Saving goes through core's save pipeline, so the error toast, the 422 field errors and
the dirty-state guard are core's rather than rebuilt here.

Added: a settings screen under Control Panel → Addon Settings

Eight keys are editable per brand without a deploy: the timezone and visibility a new event starts
with, the five calendar feed keys, and the listing page size. Everything not changed keeps following
config/events.php, so an upgrade still moves the defaults.

Screen, form, validation, store and permission check come from
goldnead/statamic-brand-context (now required at ^1.13); this package contributes the field list
in Goldnead\Events\Support\Settings and one new permission, manage events settings. The two
existing permissions are untouched.

The new permission is held by nobody until it is given to a role: until then the section is
invisible, including to users who may do everything else with this addon.

The ^1.13 floor is not cosmetic. Older releases carry the screen but do not apply its values
reliably. On a single-brand install the settings of the addons that registered last were not
applied at all — the screen showed the stored value after a reload while config() kept answering
with the packaged one, and the brand switch that would have caught up never happens where there is
one brand. And up to 1.12 a second save of the same section deleted the override made by the first,
without a message. Anyone who set values between 06.09. and this update should check the screen
afterwards: lost values do not come back on their own.

Three keys are deliberately not on the screen, and the group descriptions say so: cp.enabled and
bridges.activity are read while the application boots, so a switch here would only take effect on
the next deploy, and types is a handle-to-label map that no settings field type can edit honestly.