Update dependencies

Composer: Laravel 13.35, Livewire 4.4.7, Octane 2.21, Fortify 1.41,
Boost 2.10.3 and Pest 5.3.1, with the packages they bring (51 in all,
brick/math to 1.0). league/commonmark 2.10.3 closes a high and a medium
advisory. npm: Vite 8.3.4 and Playwright 1.64; npm audit fix updates
source-map-js past a high advisory. Both audits are now clean.

Boost's update rewrote its guidelines in CLAUDE.md and four skills.

The Gitea workflows move to the current majors of checkout, setup-node
and the Docker actions, which run on Node 24 instead of the end-of-life
Node 20. QEMU stays pinned to 9.2.2: 10.2 still segfaults on the arm64
runner.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

.claude/skills/infer-conventions/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: infer-conventions
-description: "Use this skill to analyze how a Laravel application is actually written and record its conventions as shared rules. Trigger when the user wants to detect, infer, document, or standardize project conventions or coding style, set up or grow `.ai/rules`, resolve mixed or conflicting patterns (e.g. \"are we using Form Requests or inline validation?\"), or onboard agents and teammates to \"how we do things here\". Covers: a systematic sweep of ~49 Laravel convention dimensions (validation, models, architecture, testing, frontend, database, console), open-ended house-pattern discovery, conflict reporting, and recording rules scoped to the right paths via the Boost `record-rule` MCP tool. Only run this skill when the user explicitly asks for it; never start a sweep as part of another task. Do not use for one-off code review, enforcing formatting a linter already handles, or editing `.ai/rules` files by hand."
+description: "Use this skill to analyze how a Laravel application is actually written and record its conventions as shared rules. Trigger when the user wants to detect, infer, document, or standardize project conventions or coding style, set up or grow `.ai/rules`, resolve mixed or conflicting patterns (e.g. \"are we using Form Requests or inline validation?\"), or onboard agents and teammates to \"how we do things here\". Covers: a systematic sweep of ~49 Laravel convention dimensions (validation, models, architecture, testing, frontend, database, API responses), open-ended house-pattern discovery, conflict reporting, and recording rules scoped to the right paths via the Boost `record-rule` MCP tool. Only run this skill when the user explicitly asks for it; never start a sweep as part of another task. Do not use for one-off code review, enforcing formatting a linter already handles, or editing `.ai/rules` files by hand."
 disable-model-invocation: true
 license: MIT
 metadata:

.claude/skills/infer-conventions/references/checklist.md

@@ -9,11 +9,11 @@ Each item gives the fork, then a hint (a grep or dir to spot which side the app
 ## A. Validation & HTTP input
 
 1. Validation entry point: inline `$request->validate()` vs Form Request classes vs `Validator::make()`.
-   - Hint: `ls app/Http/Requests`; grep `->validate(` / `Validator::make(` in `app/Http/Controllers`.
+   - Hint: `ls app/Http/Requests`; grep -- `->validate(` / `Validator::make(` in `app/Http/Controllers`.
 2. Custom rule location: invokable rule objects in `app/Rules` vs inline closures vs `Validator::extend()` in a provider. Rule objects are the default `make:rule` path, so record only if the app leans on closures or `Validator::extend` instead. "No rule objects" alone is just no-signal.
    - Hint: `ls app/Rules`; grep `Validator::extend` in `app/Providers`.
 3. Typed input retrieval: typed getters (`$request->string()`, `->integer()`, `->enum()`, `->date()`) vs raw `$request->input()` / dynamic properties.
-   - Hint: grep `->string(` / `->integer(` / `->enum(` vs `->input(` in `app/Http`.
+   - Hint: grep -- `->string(` / `->integer(` / `->enum(` vs `->input(` in `app/Http`.
 4. Custom messages/attributes: `lang/*/validation.php` vs Form Request `messages()` / `attributes()` methods.
    - Hint: `ls lang`; grep `function messages`, `function attributes` in `app/Http/Requests`.
 
@@ -26,7 +26,7 @@ Each item gives the fork, then a hint (a grep or dir to spot which side the app
 7. Route handler style: closures in `routes/*.php` vs controller classes.
    - Hint: count `function ()` vs `::class` in `routes/web.php`, `routes/api.php`.
 8. Middleware assignment: route/group `->middleware()` vs controller `HasMiddleware::middleware()` vs `#[Middleware]` attribute.
-   - Hint: grep `implements HasMiddleware`, `#[Middleware(` in controllers vs `->middleware(` in routes.
+   - Hint: grep -- `implements HasMiddleware`, `#[Middleware(` in controllers vs `->middleware(` in routes.
 9. Route model binding: implicit (type-hinted models) vs explicit `Route::bind` vs manual `findOrFail`.
    - Hint: typed model params in signatures vs `findOrFail(` in controllers; grep `Route::bind`.
 10. Rate limiting: named `RateLimiter::for()` + `throttle:name` vs inline `throttle:60,1`.
@@ -37,7 +37,7 @@ Each item gives the fork, then a hint (a grep or dir to spot which side the app
 11. Authorization home: Gates (`Gate::define`) vs Policy classes in `app/Policies`.
     - Hint: `ls app/Policies`; grep `Gate::define` in `app/Providers`.
 12. Authorization call site: `$this->authorize()` / `Gate::authorize()` vs `$user->can()` vs `can` middleware vs `#[Authorize]` vs `@can` in Blade.
-    - Hint: grep `authorize(`, `->can(`, `middleware('can:`, `#[Authorize(`, `@can(`.
+    - Hint: grep -- `authorize(`, `->can(`, `middleware('can:`, `#[Authorize(`, `@can(`.
 
 ## D. Eloquent & models
 
@@ -56,7 +56,7 @@ Each item gives the fork, then a hint (a grep or dir to spot which side the app
 19. Model events: observers (`app/Observers`, `#[ObservedBy]`) vs `booted()` closures vs event classes.
     - Hint: `ls app/Observers`; grep `booted`, `::observe`, `#[ObservedBy]`.
 20. Eager-load posture: explicit per-query `->with()` vs model-level `$with` defaults. Treat `preventLazyLoading()` separately as a development guard because it can complement either posture.
-    - Hint: grep `protected $with`, `->with(`, and separately `preventLazyLoading` in `app/`.
+    - Hint: grep -- `protected $with`, `->with(`, and separately `preventLazyLoading` in `app/`.
 
 ## E. Architecture & organization
 
@@ -91,11 +91,11 @@ This app ships a frontend stack, so the items below apply.
 ## G. Database & migrations
 
 33. Foreign keys: `foreignId()->constrained()` vs `foreignIdFor(Model::class)` vs manual `foreign()->references()->on()`.
-    - Hint: grep `foreignId(`, `foreignIdFor(`, `->foreign(` in `database/migrations`.
+    - Hint: grep -- `foreignId(`, `foreignIdFor(`, `->foreign(` in `database/migrations`.
 34. `down()` methods: real reverse logic vs omitted / one-way migrations.
     - Hint: grep `function down` vs the migration count.
 35. Enum storage: DB `enum()` column vs `string()` + PHP-enum cast on the model.
-    - Hint: grep `->enum(` in migrations vs string columns cast to enums.
+    - Hint: grep -- `->enum(` in migrations vs string columns cast to enums.
 36. Transactions: `DB::transaction(fn ...)` closure vs manual `beginTransaction` / `commit` / `rollBack`.
     - Hint: grep `DB::transaction`, `beginTransaction` in `app/`.
 37. Idempotent writes: `upsert` / `updateOrCreate` / `firstOrCreate` vs find-then-save.
@@ -110,14 +110,14 @@ This app ships a frontend stack, so the items below apply.
 40. Fixtures: compare how equivalent test-owned records are created, such as factories vs manual inserts. Track seeders separately for shared reference data because `$this->seed()` commonly and legitimately coexists with factories.
     - Hint: grep `::factory(` and direct inserts in `tests/`; separately inspect `$this->seed(` calls and what those seeders provide.
 41. Collaborator isolation: how the app doubles its own classes, Mockery `mock()` / `spy()` vs real integration. Ignore facade fakes like `Mail::fake()` here, they isolate framework services by default and are not a fork against Mockery.
-    - Hint: grep `->mock(`, `->spy(`, `Mockery::` in `tests/`.
+    - Hint: grep -- `->mock(`, `->spy(`, `Mockery::` in `tests/`.
 42. Endpoint assertions: array `assertJson([...])` / `assertJsonFragment` vs fluent `AssertableJson`.
     - Hint: grep `AssertableJson`, `assertJsonFragment` in `tests/`.
 
 ## I. Responses & API resources
 
 43. Response shape: API Resource classes vs `response()->json()` vs returning models/arrays directly.
-    - Hint: `ls app/Http/Resources`; grep `JsonResource`, `->json(` in controllers.
+    - Hint: `ls app/Http/Resources`; grep -- `JsonResource`, `->json(` in controllers.
 44. Resource relationship inclusion: `whenLoaded()` guards vs unconditional relationship access. Do not count ordinary scalar attributes as rivals to conditional relationships, and evaluate general `when()` fields separately.
     - Hint: compare relationship fields using `whenLoaded(` with unconditional relationship property access in `app/Http/Resources`.
 45. Pagination contracts: within comparable endpoint categories, length-aware `paginate()` vs `simplePaginate()` vs `cursorPaginate()`. These have different totals, navigation, ordering, and performance contracts, so record only a stable path-scoped API policy, never a project-wide majority.
@@ -128,7 +128,7 @@ This app ships a frontend stack, so the items below apply.
 ## J. Strings, collections & dates
 
 47. Iteration idiom: `collect()->map()->filter()` pipelines vs `array_map` / `foreach`.
-    - Hint: grep `collect(`, `->map(` vs `array_map`, `foreach` density in `app/`.
+    - Hint: grep -- `collect(`, `->map(` vs `array_map`, `foreach` density in `app/`.
 48. String API: fluent `Str::of()->...` (Stringable) vs static `Str::` vs native (`trim`, `strtoupper`).
     - Hint: grep `Str::of(` vs `Str::` vs native string funcs.
 49. Dates: compare equivalent construction call styles (`now()` / `today()` helpers vs `Carbon::`) separately from the application's mutable/immutable date policy. `Date::use(CarbonImmutable::class)` can make helpers return immutable dates, so those signals are complementary rather than conflicting.