[FIX] resource_booking: portal home and listing tolerate users without read access

[dnplkndll]

Summary

A user landing on /my that lacks resource.booking read access (e.g. an internal user not added to resource_booking.group_user, or an internal account created by another website-facing module) used to hit a hard AccessError:

• _prepare_home_portal_values called search_count([]) unguarded, breaking the entire portal home page when booking_count was in counters.
• portal_my_bookings called search_count([]) unguarded, breaking the /my/bookings listing for the same users.

Both paths now check Booking.has_access("read") and degrade gracefully (zero counter, empty list page). Portal users with the dedicated ACL row keep the existing behavior unchanged.

Distinct from upstream 1c59c21

The recent OCA fix 1c59c21 [FIX] resource_booking: access error on normal calendar addresses a different surface — it adds groups="resource_booking.group_user" to the resource_booking_ids field on the calendar.event form so non-booking users opening a calendar event don't see the (forbidden) field.

This PR addresses the portal path, not the backend calendar form. Both fixes are needed.

Tests

• test_portal_home_no_resource_booking_access — internal user without booking ACL row gets a 200 response on /my (no traceback / AccessError in response body).
• test_portal_my_bookings_no_access_renders_empty — same user gets a 200 on /my/bookings, rendering an empty list page.

Test plan

• CI green
• Runboat build comes up
• Manual: log in as an internal base.group_user (no resource_booking.group_user membership) and confirm /my and /my/bookings render without errors.

Provenance

Surgical extraction from Brenden Eshbach's (Techsystech) work on the website_appointment_booking PR fork: see review branch `18.0-techsystech-review-resource_booking`.

[dnplkndll]

CI fix

First push failed test_portal_scheduling_conflict (pre-existing test asserting the date display includes (UTC) tz label). Root cause: I had bundled an unrelated tz-context refactor in _get_booking_sudo (removed the tz=... kwarg, added it back at the schedule call site only). That changed how the calendar event date renders on the booking page and broke the assertion.

Reverted the tz refactor — this PR is now strictly the two has_access("read") guards on _prepare_home_portal_values and portal_my_bookings. The new tests still cover the regression. The tz refactor was Brenden's bundling, not actually required for the access fix; if we want it later it can be its own PR with the corresponding test update.

Diff scope after revert: 5 files (controllers/portal.py, tests/test_portal.py, manifest.py version bump, README.rst + index.html re-gen), +70/-26.

[dnplkndll]

OCA upstream readiness cleanup

Force-pushed an amend that drops two non-substantive files from the diff so this branch is ready to lift directly into an OCA upstream PR:

• Reverted resource_booking/__manifest__.py version bump — OCA convention is that contributors don't bump; /ocabot merge {patch|minor|major} does it on merge.
• Reverted resource_booking/README.rst and static/description/index.html — these are auto-generated by oca-gen-addon-readme from readme/* fragments. The pre-existing diff was pure generator-version drift (pinned maintainer-tools version produces slightly different output than what currently lives in upstream); the OCA bot regenerates post-merge so these should not appear in a PR.

The substantive code/tests are unchanged. Used SKIP=oca-gen-addon-readme git commit --amend so the regen hook didn't re-stage the bot files; all other pre-commit hooks ran clean.

Reference: OCA quality checklist, rules A3 (no manual version bumps) and A5 (no direct README.rst edits).