request->id returns the global counter, not the request's own id

Status: confirmed against main @ 21bc21d9

lib/Dancer2/Core/Request.pm:115. new stores the per-request id at line 81 ($self->{'id'} = ++$_id;), but the accessor returns the package global:

our $_id = 0;
sub id { $_id }        # returns the most recently constructed request's id

Reproduction

perl -Ilib -e 'use Dancer2::Core::Request;
  sub mk { Dancer2::Core::Request->new(env=>{REQUEST_METHOD=>"GET",PATH_INFO=>"/",QUERY_STRING=>"",
    "psgi.url_scheme"=>"http",SERVER_NAME=>"l",SERVER_PORT=>80}) }
  my ($a,$b,$c) = (mk(),mk(),mk());
  printf "->id=%s (own {id}=%s)\n", $_->id, $_->{id} for $a,$b,$c'

->id=3 (own {id}=1)
->id=3 (own {id}=2)
->id=3 (own {id}=3)

Impact

Dancer2::Core::Role::Logger:145 uses this for the %i "request ID" log format character, and forward constructs a new request via _shallow_clone. So any forwarded request mislabels its own log lines, and to_string reports the wrong id. In a persistent server, every live request object reports the same number — which defeats the entire purpose of a request id in logs.

Suggested fix

sub id { $_[0]->{'id'} }

Keep $_id as the private counter. Worth checking t/ for anything asserting the current (wrong) behaviour.

Suggested test

Three distinct requests report three distinct ->id values, and a forwarded request keeps its own.

Start in lib/Dancer2/Core/Request.pm, comparing the id assigned in new with the id accessor around line 115. Check t/ for assertions of the current behavior, then review Dancer2::Core::Role::Logger and _shallow_clone for affected uses. Done means distinct requests, including forwarded requests, report their own IDs and the relevant tests pass.