Refactor Dart Dot Shorthands

Apply Dart 3.7+ dot shorthands (member access shorthands) to simplify code where the context type is already known.

Constraints

• Single Package Focus: Only apply changes to a single package in pkgs/ at a time. Do not spread changes across multiple packages in a single operation.
• CI Usage: Only run dart tool/ci.dart --all --fast if changes are made to packages that are part of the top-level pub workspace (as defined in the root pubspec.yaml). If the package is not in the workspace, use local validation (dart analyze, dart test) within that package's directory.
• No .new Shorthand: Do not use .new as a shorthand for constructors (e.g., keep MyClass() or MyClass.new() if explicit, but do not refactor to just .new()).
• Immediate Clarity: Only use dot shorthands if the type is immediately clear from the line itself (e.g., in a typed variable declaration, a switch on a variable with a clear type, or a collection with an explicit type argument). Do not use them if identifying the type requires scrolling or searching elsewhere in the file.
• No Explicit Typing for Shorthands: DO NOT add explicit type arguments to collections (e.g., changing const x = [...] to const x = <Type>[...]) or explicit types to variables just to enable the use of dot shorthands. Shorthands should only be used where the context type is already explicitly defined in the existing code.
• Variable/Parameter Naming: Only use shorthands if the variable or parameter name contains the type name (or a very clear abbreviation). Avoid renaming variables or parameters solely to enable shorthands, especially if they are part of a public API or used in many locations.
• Avoid Complex Contexts: Avoid using shorthands in complex contexts where inference might be brittle, such as inside nested tuples in switch statements, unless the analysis tool confirms it's valid.
• Maintain Formatting: When refactoring lists or collections, preserve the original formatting (e.g., multiline lists with trailing commas). Do not squash them into a single line.
• No Redundant Shorthands: Do not use dot shorthands if the member is already accessible without any qualifier (e.g., inside the class where the static member is defined). Prefer member over .member if both work.
• Iterative Progress Tracking: You MUST update SHORTHAND_PROGRESS.md after processing each file (or a small batch of no more than 3 files). This ensures progress is visible and prevents losing work if the session is interrupted. Do not wait until the end of the package to update the progress file.

Workflow