engineer: add LogBuilderTruncateRule (closes #8)

[Goosterhof]

Summary

New sibling rule LogBuilderTruncateRule covering Builder->truncate() calls where the fluent chain's most recent table() / from() invocation targets a Log-named table (string-literal first argument matching 'log' / 'logs', case-insensitive). Closes ADR-0001 §Append-only's bluntest delete surface: DB::table('logs')->truncate() and its connection-aware / instance-shape / Eloquent\Builder variants.

Detection contract

Fires when all three hold:

1. The MethodCall name is truncate.
2. The receiver type is a (subtype of) Illuminate\Database\Query\Builder or Illuminate\Database\Eloquent\Builder — type-based via ObjectType::isSuperTypeOf(), mirroring EnforceAuditSnapshotOnRetryRule's ConnectionInterface pattern.
3. Walking back through the chain, the most recent table() or from() call has a Scalar\String_ first argument whose value substring-matches 'log' / 'logs' case-insensitively.

Strategy: sibling rule (not LogRule extension)

Per Commander disposition 2026-05-13, strategy (b). Rationale: the chain-walk machinery is genuinely different from LogRule's class-name substring match; each rule stays one-job, one-test-file, one-fixture-folder. Both rules share the logRule.logModification identifier so consumer phpstan.neon ignoreErrors entries cover both rules with one entry — the unity contract.

Fixtures (7 total)

Positive (4):

• TruncatesLogsViaFacade.php — DB::table('audit_logs')->truncate()
• TruncatesLogsViaConnection.php — DB::connection('central')->table('logs')->truncate()
• TruncatesLogsViaInjectedDb.php — $this->db->table('logs')->where('id', 1)->truncate() (instance-injected ConnectionInterface, with where() hop to exercise the chain-walk advance branch)
• TruncatesLogsViaEloquentBuilder.php — AuditLog::query()->from('audit_logs')->truncate() (Eloquent\Builder branch)

Negative (3):

• TruncatesRegularTable.php — DB::table('users')->truncate() (non-Log table)
• TruncatesDynamicTable.php — $t = 'logs'; DB::table($t)->truncate() (variable table name — acceptable miss)
• TruncatesUnrelatedReceiver.php — custom service exposing table() + truncate() methods (guards against false-positive on method-name alone — receiver-type gate short-circuits before chain walk)

Out of scope

• Variable table names ($t = 'logs'; DB::table($t)->truncate()) — would need value-flow analysis. Acceptable miss; rely on reviewer + consumer-side phpstan.neon ignoreErrors.
• Other write methods on Builder (->update(), ->delete()) on Log-named tables — distinct shape, not in issue LogRule: cover Builder->truncate() on Log-named tables #8.
• Pre-cascade audit across consumer territories (emmie, kendo, entreezuil, ublgenie, brick-inventory) — DEFERRED to the release PR per package convention.

Versioning

Per ADR-0021 §Versioning, this is a candidate Major bump (new errors in code that previously passed). Within 0.x this rolls into v0.3.0 alongside the staged LogRule static-call expansion — both ride the same release. The pre-cascade audit is mandated by the CHANGELOG [Unreleased] entry and must complete before tagging.

Verification gates (all green locally)

• composer test: 50 tests, 86 assertions (7 new)
• composer phpstan: level max, clean
• composer format:check: Pint clean
• composer coverage:check: 86.25% (≥83% threshold)
• composer mutation:ci: MSI 81.15%, Covered MSI 81.15% (≥75% / 75% thresholds)

Test plan

• CI: PHPUnit (8.4 + 8.5 matrix legs)
• CI: PHPStan self-analysis at level max
• CI: Pint format check
• CI: Coverage threshold gate (83%)
• CI: Infection mutation gate (75% MSI / 75% Covered MSI)
• Reviewer: confirm LogRule and LogBuilderTruncateRule both fire logRule.logModification on their respective fixtures (suppressing this identifier in a consumer phpstan.neon silences both)
• Reviewer: confirm chain-walk's from() recognition (judgment call beyond strict order text — see "Notes" below)

Notes

• Resolves issue LogRule: cover Builder->truncate() on Log-named tables #8.
• The chain-walk recognises both table() and from() as table-name sources. The orders specified table() only, but Eloquent\Builder chains naturally hop through from() while Query\Builder chains hop through table() — same intent, different fluent vocabulary. The Eloquent\Builder positive fixture (AuditLog::query()->from('audit_logs')->truncate()) hits the from() path; without this extension the Eloquent\Builder branch of receiver detection would be structurally unreachable under typical Laravel call shapes (Model::query()->truncate() has no table() call in the chain).