feat(privacy): add view.public.reservation.details setting

[lucs7]

Problem

With privacy.view.schedules and privacy.view.reservations set to
true, public (not logged-in) visitors see reservation labels on the
schedule. Opening a reservation, either from the popup or from
view-reservation.php, fails with:

Can't see reservation details because you don't have permissions to
any of the resources in this reservation

Both places look up resource permissions by UserId. A public session
has UserId = 0, so the lookup is always empty. This worked up to
2.8.6 and regressed in 2.8.6.2 (see #444).

Change

Add privacy.view.public.reservation.details (boolean, default
false). When it and privacy.view.reservations are both true, the
popup (ReservationPopupPresenter) and the detail page
(ReservationDetailsBinder) grant a public user the resources of the
reservation they opened, instead of querying permission rows.

• The shared condition is
  ReservationDetailsFilter::CanPublicViewDetails().
• Logged-in users are unaffected and keep the existing lookup.
• Env var: LB_PRIVACY_VIEW_PUBLIC_RESERVATION_DETAILS.
• config.dist.php and .env.example are regenerated; docs updated in
  ADMINISTRATION.rst and BASIC-CONFIGURATION.rst.

Why a new setting

Changing what privacy.view.reservations does would expose details on
existing installs without any config change, which could be a security
regression. This was raised in the review of #1331. With the new
setting defaulting to false, upgrades behave exactly as before.

Not included

• SlotLabelFactory: the schedule labels are already handled on
  develop.
• The per-resource visibility of a reservation's resources is not
  filtered; a public user sees all resources of a reservation they can
  already see on the public schedule.

Testing

• ReservationDetailsFilterTest: both settings on, either setting off,
  and a logged-in user.
• ReservationPopupPresenterTest: a public user gets the reservation's
  resource IDs bound.
• composer config-dist:check and composer env-example:check pass.
• Two existing tests fail the same way on a clean develop
  (ConfigTest::testHistoricalLegacyConfigDevelParsesCorrectly,
  PluginConfigLoadingTest::testPluginConfigValidation).

Not yet verified manually in a running instance: set both settings to
true, open a reservation from the public schedule in a private
window, and open view-reservation.php?rn=<reference number>.

Credit

Builds on the approach of #1331 by Norbert Krings, reworked to sit
behind a new setting as suggested in the review.

Related: #444, #1331

🤖 Generated with Claude Code