ci: add CodeQL analysis over the real colcon build

[benaliabderrahmane]

Description

Adds CodeQL analysis over the real colcon build. Free on public repositories,
native to GitHub, and one workflow file with no ongoing upkeep.

What it adds over build-and-test is the interprocedural class of bug: use-after-free,
buffer overflow, null dereference on a path no test happens to take. For a codebase
that hands raw endpoint pointers between an epoll dispatch and whatever thread is
tearing an endpoint down, and memcpys fixed-size buffers out of shared memory,
that is the half worth having.

This is the advanced setup (a committed workflow), not the one-click default
setup, and the reason matters. Default setup runs autobuild. Autobuild guesses
at the build system and would invoke cmake without the ROS environment sourced,
so find_package(rmw) fails, nothing compiles, and CodeQL uploads an empty
database — a green check that means nothing. build-mode: manual puts the
tracer around the same colcon build --paths rmw_unix_socket_cpp that CI runs, in
the same ros:jazzy-ros-base container, so the extractor observes the real
compiler invocations with the real headers.

Is this user-facing behavior change?

No. CI configuration only; no source, build or packaging change.

How was this tested?

The workflow triggers on pull_request against devel, so this PR is its own
test — the analyze (c-cpp) check on this PR is a real run of the thing being
added. Worth confirming two specific things in that run before merging:

1. The build step compiled something. If find_package had failed, CodeQL
   would still report success over an empty database. The build log should show
   the package's translation units compiling.
2. CodeQL init works inside the container. The action is documented as
   container-compatible, but that is the part I could not verify locally.

Locally I verified only that the YAML parses and that the build command it runs is
the one that works. Everything else is what the first CI run is for.

Did you use Generative AI?

Additional Information

Two deliberate differences from ci.yml:

• Debug instead of Release. At -O2 the inlining and constant folding
  remove enough structure that some dataflow paths stop being visible to the
  extractor.
• One distro, not the four-distro matrix. The analysis is over our sources,
  which do not differ per distro; the matrix exists to catch per-distro API drift,
  which is a build problem rather than an analysis one.

Query pack is security-and-quality, the superset that adds correctness and
maintainability queries on top of security-extended. If the quality half proves
noisy, dropping to security-extended is a one-line change.

Also runs weekly on a schedule so a query-pack update is applied to existing code
rather than waiting for the next push to touch it.

Independent of the other open PRs — touches only .github/workflows/.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.