[Bug] Docker entrypoint auth bootstrap is unsafe for mounted and upgraded configs

## Problem

The Docker entrypoint bootstraps authentication with `grep`/`sed` against
`conf/rest-server.properties`. That works for the shipped defaults it was
written for, but not for mounted configs, upgraded volumes, or any value whose
encoding differs between shell and `HugeConfig`.

Concrete cases, most of them raised during review of #3119:

- **Gremlin and REST can end up on different auth providers.** The check is a
presence-only `grep` for `auth.authenticator`, so a config that already has
the REST property but not the Gremlin side is treated as fully configured.
- **A pre-existing authenticated volume can fail its first startup after
upgrade.** A legacy volume can carry `docker/init_complete` while the
bootstrap state the entrypoint now expects is absent.
- **`PASSWORD` is observable.** It is currently handed to Java as a command-line
argument, which puts it in `ps` output for every process in the container.
- **`sed` rewriting does not implement the Java properties grammar.** Escaped
keys, `:` and whitespace separators, continuations, and duplicate logical
definitions are all read differently by `HugeConfig` than by the entrypoint.
Concretely, `set_prop` detects only `key=`, so a mounted config using `:`
gets a second logical definition appended and `HugeConfig` then rejects the
file as a list. This affects `backend` and `pd.peers` as well as
`init_store.enabled`, so the fix should cover all of them together.
- **`PASSWORD` silently does nothing when init-store is skipped.** `init-store`
reads it from stdin, and the disabled path returns before that, so the admin
is created on the PD startup path from `auth.admin_pa` — public default `pa`.
#3119 documents this and warns at runtime; it does not fix it.

The first case, as it stands on master `98477f0f5`: the entrypoint no longer
greps for `auth.authenticator` itself, it calls `bin/enable-auth.sh` whenever
`PASSWORD` is set, and that script gates only on whether `conf-bak/` exists.
On a config it did not write, it appends a second definition to both files,
and the two parsers disagree about which one wins.


## Proposal

Move property reading and writing off `grep`/`sed` and onto the same
Commons Configuration path `HugeConfig` uses, so both sides agree on encoding,
and let the entrypoint delegate auth classification to it.

Rough shape:

- a small `ConfigTool` CLI for typed get/set against a properties file,
preserving comments, file mode, and inode for mounted configs;
- entrypoint uses it instead of `grep`/`sed`, and stops passing secrets as
process arguments;
- auth bootstrap becomes explicit about mounted, upgraded, and custom
authenticator cases rather than inferring from one key's presence;
- a shell test suite covering the entrypoint contract, wired into
`docker-build-ci.yml`.

## Scope

In scope: `docker-entrypoint.sh`, the new config CLI and its wrapper, the
entrypoint test suite, and the workflow path filters that run it.

Out of scope: the `init_store.enabled` option and its gate (#3118 / #3119),
Helm chart structure, and `GraphManager` behavior.

## Context

This work originally shared a branch with #3119. That made a ~2,900-line diff
covering two unrelated ideas, so it was split out to keep each reviewable on
its own. #3119 now carries only the option, the gate, the env mapping, and the
init-flag guard.

Start with docker-entrypoint.sh and bin/enable-auth.sh to trace the current authentication bootstrap and property rewriting paths. Then inspect the proposed config CLI scope, the entrypoint test suite, and docker-build-ci.yml path filters. Done means mounted and upgraded configurations are handled consistently, secrets are not exposed as process arguments, and the listed shell tests cover the entrypoint contract.

Written by the indexing model from the issue text.