fix(dsl): resolve modifier applications through the receiver (#100)

[JArmandoAnaya]

An actor-associated modifier could not be applied at all — in either of the two
positions §7.3.12.4.1 defines. This unblocks p8-s3 (#46), whose whole surface is
§8.9's seventeen movement modifiers.

The cause

§7.3.12.2 says an actor-associated modifier's name is "a unique name … in the
actor scope". The declaration modifier vehicle.keep_lane therefore interns
under the actor's qualified name, and ordinary lookup for keep_lane finds
nothing — which is exactly what the application site was doing.

The fix

Application resolves the actor expression's type and walks its inheritance
chain, probing the name table once per step. That is an exact map lookup per
supertype, not a scan, so it stays deterministic and costs nothing at library
scale.

With the actor omitted, the receiver is what the site already implies:

• member position — the enclosing declaration, which is §7.3.12.4.2's third
  example (a modifier applied inside an actor declaration, applying to every
  instance), or the actor a behavior is declared on;
• with: block — the invoked behavior's actor, which is what
  §7.3.12.4.1 means by "can be omitted when it is the same as the scenario actor
  the modifier is applied in" and what Code 57 shows.

The larger half of the bug: a with: block was not validated at all.
no_such_modifier(1) inside one was accepted silently, and the with: block is
where the domain model expects nearly every movement modifier to be applied.

The check moved from resolution pass 3 to pass 4, because resolving a receiver
means typing an expression and that needs an ExpressionContext. Nothing holds
a TypeInfo& across the typing call, which can grow Program::types.

Two diagnostics got better on the way:

• a name that exists but is not a modifier now says what it is, instead of
  "unknown modifier";
• a modifier belonging to an unrelated actor says so — modifier 'keep_lane' belongs to 'vehicle' and cannot be applied to 'std::person' — instead of
  claiming the name does not exist.

Tests

• dsl_types_test.cpp +8: both positions, an inherited receiver, an actor
  applying its own modifier without naming itself, an unrelated actor rejected,
  argument names checked inside a with: block, and the not-a-modifier message.
• dsl_stdlib_test.cpp +3: modifiers from §8.7, §8.9 and §8.12.2 applied from
  both positions; person.keep_lane() rejected; and the three unassociated
  §8.9 modifiers applied plainly, since the §8.8/§8.9 name collision gives them
  a different application path from their fourteen associated siblings.

1321 gtest (+11), 194 pytest. No existing test relied on the silent acceptance.

No ADR

The scoping model is the standard's, stated outright in §7.3.12.2 — this makes
the implementation match it rather than deciding anything. The reasoning lives
in code comments, frontends/dsl/README.md and this issue's trail.

Closes #100