Fix nested job request_id chaining

[silva96]

Problem

When a job enqueues another job from within its execution context, the nested job's enqueue log has no request_id (only ActiveJob tags with the parent job's ID).

Previously, this caused nested jobs to lose the request_id trail:

HTTP request (req-123) → JobA (job-a-456)
  ↓
JobA enqueues JobB → Enqueue log has NO request_id ❌
  ↓
JobB execution logs couldn't be traced back to req-123 ❌

Solution

Implement request_id chaining through parent jobs:

1. When registering a job enqueue, if the entry has no request_id, check its tags
2. Extract the parent job_id from tags (e.g., ['ActiveJob', 'JobA', 'job-a-456'])
3. Look up the parent job's request_id from State
4. Register the new job with the parent's request_id

This works for arbitrarily deep nesting:

HTTP request (req-123)
  ↓ registers: job-a → req-123
JobA enqueues JobB
  ↓ looks up job-a → req-123, registers: job-b → req-123
JobB enqueues JobC
  ↓ looks up job-b → req-123, registers: job-c → req-123
JobC enqueues JobD
  ... and so on!

Changes

• Updated Parser.register_job_enqueue to chain request_id lookups through parent jobs
• Added test for 2-level nested jobs (HTTP → JobA → JobB)
• Added test for 3-level nested jobs (HTTP → JobA → JobB → JobC)

Test Results

✅ All 98 tests pass with 378 assertions

# Example: 3-level nested job chain
HTTP request (req-999)
  ↓
JobA (job-a-111) - traced to req-999 ✅
  ↓
JobB (job-b-222) - traced to req-999 ✅
  ↓
JobC (job-c-333) - traced to req-999 ✅

All job logs are now correctly grouped under the original HTTP request, regardless of nesting depth! 🎯