[performance-profiler] Optimize RFC3164 BSD timestamp parsing

Recommendation: candidate

Hot path: `libbeat/reader/syslog/message.go:104-115`, `(*message).setTimestampBSD`. RFC3164 parsing calls `time.ParseInLocation(time.Stamp, v, loc)` for every BSD-style syslog timestamp.

Evidence:
- Baseline command: `go test -run '^$' -bench 'BenchmarkParseRFC3164/ok$' -benchmem -cpuprofile .perf-profiler/syslog.cpu -memprofile .perf-profiler/syslog.mem -count=5 ./libbeat/reader/syslog`
- Baseline results: `2657`, `2388`, `2246`, `2450`, `2698 ns/op`, `0 B/op`, `0 allocs/op` (median `2450 ns/op`).
- Baseline CPU profile: `time.parse` was `1410ms/3400ms` cumulative (`41.47%`); `parseRFC3164` was `3180ms/3400ms` cumulative (`93.53%`).

Experimental change tested locally (not committed): add a fast path in `setTimestampBSD` that manually parses the fixed `time.Stamp` shape (`Jan _2 15:04:05`) into month/day/hour/min/sec, validates ranges, and uses `time.Date(time.Now().In(loc).Year(), ...)`; fall back to the existing `time.ParseInLocation` path for malformed inputs to preserve existing error behavior.

Validation/after data:
- Test command: `go test -run 'TestMessage_SetTimestampBSD|TestParseRFC3164' ./libbeat/reader/syslog`
- After benchmark: `242.4`, `216.2`, `181.2`, `226.1`, `568.1 ns/op`, `0 B/op`, `0 allocs/op` (median `226.1 ns/op`).
- Measured improvement: median `2450 -> 226.1 ns/op`, about `90.8%` faster for the benchmarked RFC3164 BSD timestamp case.
- After CPU profile no longer showed `time.parse`; remaining cost was dominated by `time.runtimeNow` through year lookup.

Duplicate check: distinct. GitHub issue searches for `"performance-profiler" "RFC3164"`, `"performance-profiler" "setTimestampBSD"`, and `"performance-profiler" "time.ParseInLocation" "syslog"` returned zero results. `/tmp/previous-findings.json` could not be read because this execution is constrained from accessing `/tmp` paths.

Confidence: high that this is a real hot path and exceeds the 10% bar for BSD-style RFC3164 messages. Risks: manual timestamp parsing must remain byte-for-byte compatible with Go's `time.Stamp` acceptance, especially spacing, zero-padded days, invalid-date behavior, location/DST behavior, and error messages on malformed input; keeping the fallback path and adding table tests mitigates this.

---
[What is this?](https://ela.st/github-ai-tools) | [From workflow: Performance Profiler](https://github.com/elastic/beats/actions/runs/28245739515)

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
> - [x] expires on Jul 3, 2026, 3:05 PM UTC

Start in libbeat/reader/syslog/message.go:104-115 at (*message).setTimestampBSD, then read the existing TestMessage_SetTimestampBSD and TestParseRFC3164 coverage. Run the provided RFC3164 benchmark before and after the change, along with those tests. Done means faster valid BSD timestamp parsing while malformed-input behavior, spacing, dates, location handling, and benchmark allocations remain compatible.

Written by the indexing model from the issue text.