Regression: gitlab.ci option errors when unset (missing default)

Bug

When a downstream flake imports the gitlab-ci flakeModule but does not set any gitlab.ci configuration, evaluation fails with:

error: The option `perSystem.x86_64-linux.gitlab.ci' was accessed but has no value defined.

Root Cause

In nix/modules/flake/gitlab-ci.nix, the options.gitlab.ci option is defined with type = types.submoduleWith { ... } but no default = {}:

options.gitlab.ci = mkOption {
  description = "GitLab CI dynamic pipeline configuration";
  type = types.submoduleWith { ... };
  # missing: default = {};
};

The config.perSystem block uses with config.gitlab.ci; which eagerly evaluates the option before mkIf enable can short-circuit:

config.perSystem =
  { config, ... }:
  with config.gitlab.ci;
  mkIf enable { ... };

When no definition exists for gitlab.ci, the access fails.

Fix

Add default = {}; to the options.gitlab.ci mkOption. This ensures the submodule initialises with internal defaults (enable = false, etc.) even when no consumer explicitly sets it.

Impact

This is a regression affecting any repo that imports horizon-flake-parts but doesn't enable horizon.ci. High priority — blocks nix build entirely.

Test Needed

Add a test case that imports the flakeModule without setting gitlab.ci and verifies evaluation succeeds.