In the Philippines, Senior Citizens (SC) and Persons With Disabilities (PWD)
are legally entitled to statutory discounts and VAT exemptions on eligible
goods and services. The `l10n_ph_invoice` module already handles these on
customer invoices and credit notes; this extends the same privileges to
quotations and sale orders.

This adds a new `l10n_ph_sale` module, enabled like `l10n_ph_invoice` via a
separate "Discount Privileges on Sale Orders" toggle in the Philippine
Accounting settings (`module_l10n_ph_sale`, defined in `l10n_ph` next to the
invoice toggle). It mirrors the invoice implementation:

* Sale Order Line: `sale.order.line` inherits the shared
  `l10n_ph.discount.privilege.line.mixin` and provides the model-specific
  hooks (`_l10n_ph_get_discount_price_details` recomputes the gross amounts
  with the tax engine) plus helpers to adjust the price unit and taxes from
  the privilege's fiscal position. Privilege fields are propagated to the
  generated invoice lines in `_prepare_invoice_line`, so invoiced lines
  behave exactly like lines the privilege was applied on.
* Application Wizard: `l10n_ph.discount.privilege.wizard` is extended with
  `order_id` / `sale_order_line_id` so the same preview / scope-filtering /
  apply / remove-all / single-line-remove flow works on draft and sent
  quotations and sale orders.
* Sale Discounts interplay: privileged lines are excluded from the standard
  sale Discounts wizard to avoid double discounting.
* Views: "Discount Privileges" buttons below the order lines, regular/special
  discount amount columns, and the line discount becomes readonly while a
  privilege is applied.
* Security: salesmen get read access to privilege definitions and CRUD on the
  wizard; configuring privilege definitions remains reserved for Accounting.
* Tests: coverage for the wizard flows, scopes, fiscal position mappings,
  discount computations, state guards, access rights, invoice propagation and
  the sale Discounts interplay.

Task-6032201

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Description of the issue/feature this PR addresses:

Attendance records only represented check-in and check-out times. Unpaid
breaks therefore required manual time corrections and were not consistently
reflected in worked hours, overtime, the attendance systray or the kiosk flow.

Current behavior before PR:

- The complete check-in/check-out interval is treated as worked time.
- Employees cannot review and correct attendance details from the systray.
- Kiosk users cannot record their total break after checking out.

Desired behavior after PR is merged:

Add an optional company-level break management setting and store the total
break duration on each attendance. Validate that breaks apply only to closed
attendances, are non-negative and do not exceed the attendance duration.

Deduct breaks from worked hours, daily attendance totals and overtime.
Recompute overtime when a break changes and expose the break information in
the relevant attendance and employee views.

Add an attendance review to the systray showing today's sessions, check-in and
check-out details, locations, breaks and total worked duration. Allow permitted
users to edit attendance details using explicit Save and Discard actions.
Pending changes are saved before switching sessions or checking in or out,
while validation failures keep the draft available for correction.

Update the kiosk checkout flow with a dedicated dialog for recording break
minutes on the attendance that was just closed. Preserve manual, PIN and
barcode identification and keep server-side validation authoritative if the
attendance changes before the break is saved.

Add backend and HOOT coverage for break validation, worked-hours and overtime
calculations, attendance review editing and synchronization, and kiosk break
updates.

task-5252996



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr