Create agent plan content directory for backups

[loglapa]

What changed

Create ${GITLAB_SHARED_DIR}/agent_plan_content during data-directory initialization with the expected git:git ownership and 0700 permissions.

Why

GitLab backups from 19.1 can fail with ENOENT when the agent plan content directory has not been created yet. The directory is a configured backup path, but docker-gitlab does not currently initialize it.

This implements the working directory-creation workaround reported in #3269 as an idempotent container lifecycle step. The related upstream GitLab bug remains open: https://gitlab.com/gitlab-org/gitlab/-/work_items/604413

Impact

Fresh and upgraded installations get the expected directory before a backup runs, avoiding a backup failure without requiring a manual workaround.

Validation

• bash -n assets/runtime/functions
• git diff --check
• Executed the install -d command twice in a sameersbn GitLab container and verified directory type, git:git ownership, and mode 0700

Fixes #3269

[emotroshylov]

@sachilles @sameersbn @solidnerd
could you please take a look at this PR?

Our production GitLab 19.3.1 instance is currently affected by this backup issue, so we'd really appreciate if #3293 could be reviewed and merged when possible.

The workaround from #3269 is confirmed to fix the backup failure, and this PR automates that workaround.

Thanks!

[sachilles]

@loglapa Thanks for your PR in order to provide this fix.

@emotroshylov Thanks for your reminder. I'll backport this fix to currently officially supported versions (i.e. for v19.1.x, v19.2.x and v19.3.x).

Hint:

• related upstream issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/604413

[sachilles]

@loglapa Unfortunately you merged your PR to your master branch. Could you be so kind and reset this PR to commit 8251c1c?

[loglapa]

Done — the PR branch now points back to 8251c1c79b87ad1d0e96643218fe0e7eb87ff43d.

[sachilles]

Thank you!