### What problem does this solve?

Problem Summary: the identity of a join was its type and its conditions. A mark join, which implements a
non-nullable `IN` subquery as `Project(mark AS m) -> LEFT_SEMI_JOIN(mark=true, t.k = u.k)`, preserves
every row of its left side and produces a marker column, while the same semi join without the marker
drops the unmatched rows: with t = {1, 2} and u = {1} the first plan outputs two rows and the second
one, with the same join type, the same condition and the same input scans. Both plans rendered one key,
and since their inputs are identical the freshness comparison could not separate them either, so a
learned or pinned count measured on one was applied to the other.

The mark flag is now part of the join identity in both forms: the canonical string writes `J{<type>,mark,
c:[...]}` and the structural key writes the flag, so the two plans keep different keys in both literal
modes. Every join fingerprint moved once by this change (the flag is a field of the identity even when it
is false).

### Release note

A mark join and the plain semi join of the same columns no longer share an hbo statistics entry.

### Check List (For Author)

- Test: Unit Test
    - Two corpus cases pin the mark semi join and the plain one over the same scans; a test asserts their
      keys differ in both literal modes and that the canonical writes the flag. The regenerated file
      gained those cases and moved the fingerprints of the join cases (the intended change), and 200
      cases of the stats package plus the HBO command suite pass. The regression suites were not re-run
      against a FE rebuilt from this commit.
- Behavior changed: Yes - the mark-join flag is part of a join key.
- Does this need documentation: No

### What problem does this solve?

Problem Summary: the operand identity of a join expansion is the column of a table, so in a self join
both sides of an equality resolve to the same table: `t a LEFT OUTER JOIN t b ON a.k = b.v` and the same
join on `a.v = b.k` both rendered `t.k = t.v` (the pair was sorted for commutativity), and the side
information (`sides:[...]`) is the same for both sides of a self join. The two plans keep a different
number of rows, and an expansion factor pinned for one was applied to the other without any data state
to guard it.

The operands of a pair are now ordered by the side they are read from: the operand of the left child is
written first, so `a.k = b.v` and `a.v = b.k` keep different keys, while the same pair written in either
order (`b.v = a.k` against `a.k = b.v`) keeps one. An inner join stays commutative: the optimizer may
swap its children and its count does not depend on which occurrence is called the left one, so its
operands remain sorted by their identity.

### Release note

An hbo join expansion entry of an outer self join is no longer applied to the join of the same table with
the columns reversed.

### Check List (For Author)

- Test: Unit Test
    - `HboJoinConditionsTest` pins the outer self join with the columns reversed (different keys), the
      same pair written in either order (one key) and the inner self join (one key); 201 cases of the
      stats package plus the HBO command suite pass.
- Behavior changed: Yes - the operand order of an outer join expansion pair is the side it is read from.
- Does this need documentation: No

…oundary id

### What problem does this solve?

Problem Summary: the column definitions of a transparent project are inlined into the node above it, but a
side of an outer join is NULL for the rows the join does not match: a definition computed there which can
turn NULL into a non-NULL value (a coalesce, an `is null`, a udf, ...) denotes a different value above the
join. `Aggregate(gb = x)` over `LEFT_OUTER_JOIN(t.k = u.k)` with `coalesce(u.v, 0) AS x` computed on the
right side and the same expression computed above the join rendered one `A{gb:Coalesce(...)}` although the
first returns the groups `{0, NULL}` and the second `{0}`; a pinned or learned count of one applied to the
other on unchanged scans.

Every description now numbers the null extensions it contains in build order. A definition which crosses a
null-extended side is wrapped with the id of that boundary (`NullExtended<0>(Coalesce(...))`) when the
expression can turn NULL into a non-NULL value (the classification the outer join push down already uses,
extended over the sub tree, with a udf treated conservatively). The id is assigned inside one description,
which is memoized on the group, so the estimation path and the EXPLAIN path render the same marker. A
definition which cannot change its value (arithmetic, a cast, a plain column) is not wrapped, so the keys
of those plans do not move.

### Release note

A pinned or learned hbo statistics entry of a plan whose value is computed on the nullable side of an outer
join is no longer applied to the plan which computes it above the join.

### Check List (For Author)

- Test: Unit Test
    - Two corpus cases pin the pair (below the join against above it) and their keys differ in the marker;
      201 cases of the stats package plus the HBO command suite pass. The regression suites were not
      re-run against a FE rebuilt from this commit.
- Behavior changed: Yes - a null-extended definition is marked with the id of the boundary it crossed.
- Does this need documentation: No

…d report its failure

### What problem does this solve?

Problem Summary: a deletion removed the in-memory pinned entry first and the stored row second; when
the stored deletion failed the statement still succeeded, and the failure was compensated with a
tombstone that the lazy load replayed: the tombstone had to carry a generation (the create time of the
row it judged) to avoid deleting a row another FE wrote afterwards, and two FEs can capture the same
millisecond or disagree on the clock, so a newly acknowledged SET could be removed by the replayed
deletion.

The stored row is now removed first and the in-memory entry only afterwards: when the stored deletion
fails the statement fails (`AnalysisException`) and the entry stays active, so an entry the load reads
later always describes an entry the user was told is active. The tombstone bookkeeping, its generation
and the replay at load time are removed; the load installs the stored rows as they are, which makes the
whole cross-FE generation/revision question moot for the deletion path.

### Release note

`HBO DELETE STATISTICS` now fails when the persisted entry cannot be removed from the internal table,
and the entry stays active in that case.

### Check List (For Author)

- Test: Unit Test
    - `HboPinnedStatisticsRaceTest` keeps the case that a replacement is not removed and drops the
      generation cases; `HboShowStatisticsCommandTest` and the input-statistics suite pass.
- Behavior changed: Yes - a failed persisted removal now fails the statement instead of being replayed.
- Does this need documentation: No

…anup going entry by entry

### What problem does this solve?

Problem Summary: a pinned SET put the entry into memory and then wrote the stored row as a best-effort
step, so a failed write left an entry which only existed in that FE and disappeared on the next restart
without the statement saying so. A stale cleanup removed the entries one by one and the stored removal of
one of them could now abort the whole statement (its in-memory entry removed first in the previous
ordering, its row left behind).

A pinned SET writes the stored row first and, when that fails, fails the statement and leaves the memory
untouched - the same order the deletion takes, so memory and table cannot disagree about an entry the
user was told about. `HBO DELETE STALE STATISTICS` keeps going when one entry's stored row cannot be
removed: that entry stays active and is judged again by the next run, and the statement reports how many
entries it removed and how many it kept for that reason.

### Release note

`HBO SET STATISTICS` now fails when the entry cannot be persisted to the internal table, and
`HBO DELETE STALE STATISTICS` no longer aborts on one entry whose stored row cannot be removed.

### Check List (For Author)

- Test: Unit Test
    - `HboPinnedStatisticsRaceTest`, `HboShowStatisticsCommandTest` and the input-statistics suite pass
      (the persistence path is disabled in these tests, the statement-level behaviour is exercised by
      the hbo regression suites which run with the internal table enabled).
- Behavior changed: Yes - a failed persisted SET fails the statement; a stale cleanup skips such an entry.
- Does this need documentation: No

…build counter

### What problem does this solve?

Problem Summary: the boundary a definition crossed was numbered by a counter of the description being
built (`Ctx.nextBoundaryId++`). Each description is memoized per group and may be built as the root of its
own context, so the number a boundary got depended on which group was described first and on whether a
child description was already cached: describing the two-table join of a nested pair on its own numbered
it 0, and composing it later into the three-table description left it 0 while the outer boundary also got
0; when the prefilter of a pinned entry skipped the child, both boundaries were numbered inside one
context instead and became 0 and 1. The same plan therefore rendered `NullExtended<0>(NullExtended<0>(...))`
or `NullExtended<0>(NullExtended<1>(...))` depending on the cache, and a fingerprint copied from EXPLAIN no
longer matched.

A marker now carries the child indices from the boundary to the consumer instead of a number: the boundary
itself writes no index, and a node with more than one child prepends the index of the child the definition
came from. The code is a property of the assembled tree - a cached child description keeps the text of its
own subtree and the parent only prepends its index - so it is the same whatever order the descriptions were
built in, and two boundaries can no longer share a marker.

### Release note

The hbo statistics key of a plan whose value is computed below an outer join no longer depends on the order
the memo describes its groups in.

### Check List (For Author)

- Test: Unit Test
    - The regenerated corpus renders `NullExtended(...)` for the boundary of the pair case; the golden
      suite (27 cases) passes. The stats package is covered by the gate of the next commit.
- Behavior changed: Yes - the null-extension marker is a child-index code, not a boundary id.
- Does this need documentation: No

…n expansion key

### What problem does this solve?

Problem Summary: the operands of every equality were sorted on their own, which lost the incidence of a
self join: `INNER_JOIN(a.k = b.v AND a.v = b.w, Scan(t a), Scan(t b))` and the same join on
`a.v = b.k AND a.v = b.w` both rendered `{t.k = t.v, t.v = t.w}` with the operand set `{t.k, t.v, t.w}`,
although with t(k,v,w) = {(1,1,1),(2,1,2)} the first keeps one row and the second two: the first equates
the two columns of a with two columns of b, the second equates a.v with both of them. An expansion factor
pinned for one was applied to the other, and this store has no data state to guard it.

The pairs of an inner join are now ordered by one global orientation of its two sides: every operand of
the left child is written first, and the lexicographically smaller of the two possible orientations (all
pairs as given, or all pairs flipped) is the key. Flipping the whole set keeps the join commutative, while
ordering the pairs on their own lost which operands share a column. An outer join preserves a side, so its
orientation is fixed (the operand of the left child first), and a pair whose operands come from the same
side is ordered by identity.

### Release note

An hbo join expansion entry of an inner self join with several equality conditions is no longer applied to
the join with another incidence of the same columns.

### Check List (For Author)

- Test: Unit Test
    - `HboJoinConditionsTest` keeps its cases for the outer self join (the reversed columns differ), the
      either-order pair and the inner self join (one key); 200 cases of the stats package plus the HBO
      command suite pass. The multi-conjunct incidence case needs a three column scan fixture and is a
      follow-up test.
- Behavior changed: Yes - the operand order of an inner join expansion pair is one global orientation.
- Does this need documentation: No

### What problem does this solve?

Problem Summary: an expansion key named the whole condition set, residuals included, so the factor of
`a.k = b.v` could not be used by `a.k = b.v AND a.v > b.w`, and the two conditions had to be kept apart
by a residual text which itself was not oriented with the equality pairs: `INNER(a.k=b.v AND a.v>b.w)` and
`INNER(a.v=b.k AND a.v>b.w)` rendered the same key although the residual touches one of the equality
operands in the first plan only.

A key now describes the equality conditions only: the factor is the fan out of the equi join, and the non
equality conditions keep their own selectivity on top of it. `JoinEstimation` takes an expansion factor
that scales the equality estimate *before* the residual conditions are applied, and the estimator applies
the injected factor that way, so one entry serves every query with the same equality pair whatever
residual it adds, and a selective residual still lowers the estimate. A join whose equality operands are
not direct table columns still has no key.

### Release note

An hbo join expansion entry is matched by the equality conditions of a join and scales their estimate; a
residual predicate is applied on top of it. The factor of an existing entry is relative to the equality
estimate now, so entries tuned with the previous meaning should be reviewed.

### Check List (For Author)

- Test: Unit Test
    - `HboJoinConditionsTest` pins that a residual does not change the key; 200 cases of the stats package
      plus the HBO command suite pass. The regression suite which injects factors reads its numbers from
      the annotation and now asserts the reported base is at most the larger input; it has not been
      re-run against a FE rebuilt from this commit.
- Behavior changed: Yes - the key of a join expansion entry is the equality pair, and the factor scales
  the equality estimate instead of the larger input.
- Does this need documentation: Yes - the meaning of a JOIN_EXPANSION factor changed.

…ingerprint preimage

### What problem does this solve?

Problem Summary: the structural key of a group wrote the rendered text of its conditions, its branch
mappings and its header expressions as one length prefixed string. Within that string the values of an
expression were still concatenated by the printed grammar (`lit(` ... `,` ... `:type`), so a value which
carried those characters could stand for a field boundary of its own: the array `['a','b']` and the
singleton array whose element is `a:TEXT),lit(b` produced the same preimage, although they match
different rows.

The fingerprint preimage now serializes expressions structurally as well: every expression writes its
kind, its value defining fields (a literal's type and value, a slot's qualifier and name) and its
children, each with its own length, and the conditions are sorted and de-duplicated over those bytes.
A composite literal keeps one field per element, so an element cannot forge the boundary of another.
The display form (canonical, shape, EXPLAIN, the struct a user pastes) is unchanged; only the fingerprint
moves. A missing semantic field (a cast target, an order direction) is not addressed here and remains a
per-expression follow-up.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - The regenerated corpus changes only its fingerprint lines (the shapes, canonicals and scan tokens
      are byte identical); 200 cases of the stats package plus the HBO command suite pass.
- Behavior changed: Yes - all fingerprints moved once (the display form did not).
- Does this need documentation: No

### What problem does this solve?

Problem Summary: the previous commit introduced the length prefixed expression key but the condition
collections of a filter, an aggregation and a join still wrote the rendered text of their expressions
(and the join case was formatted with the new mark-join flag, so the replacement of that site did not
apply). The array literal case was therefore still one key for `['a','b']` and for the singleton array
whose element is `a:TEXT),lit(b`: the elements of a composite literal were only separated by the printed
grammar again.

The three sites now write the structural expression key as well, which also restores the identity
suffixes the display name carries (a udf's scope and id, a match analyzer, a search dsl, a lambda's
arguments, the distinct flag), the variant sub path of a slot (`v['age']` is a different column) and the
sorting/de-duplication of the conditions over their bytes. A corpus case pins the two arrays apart.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - The new corpus case `filter_with_an_injected_delimiter_array_literal` asserts the two arrays keep
      different fingerprints in both literal modes; 201 cases of the stats package plus the HBO command
      and pinned-race suites pass.
- Behavior changed: Yes - the fingerprints of the condition sites moved once (the display form did not).
- Does this need documentation: No

…it reads

### What problem does this solve?

Problem Summary: the definition of a computed column kept only the expression, not the sub tree which
produces the rows it reads, so two plans whose definitions share the expression rendered one key. With
t(v) = {0,1,1}:

    Aggregate(group by a.x)                Aggregate(group by b.x)
      Cross                                  Cross
        Project(v+1 AS a.x) -> TopN(v ASC, 2)  -> Scan(t)
        Project(v+1 AS b.x) -> TopN(v DESC, 2) -> Scan(t)

both definitions become `Add(col(t.v),lit(1))` and both grouping keys render the same though `a.x` has
two values and `b.x` one: the Cross (which names both branches) is the same in both plans, so nothing in
the key says which branch the aggregation groups by. An exact pin of the two group query therefore
applied to the one group query.

A computed definition which reads the output of a node that selects the rows (a top-n or a limit) is now
bound to that producer: the marker records the child indices from the producer to the consumer, which is
the same structural code the null extension marker uses. `NullExtended` becomes the general `Bound`, with
the null extension as the case where the crossing is gated on the definition being able to turn NULL into
a non NULL value; a row selecting boundary binds every definition. The code, a property of the assembled
tree, is the same whether the child was described fresh or reused from the memo.

### Release note

An hbo statistics entry of a plan whose computed column is bound to a top-n or a limit is no longer
applied to the plan computing the same expression over another such producer.

### Check List (For Author)

- Test: Unit Test
    - The regenerated corpus renders `Bound(...)` for the null extension pair case; 201 cases of the stats
      package plus the HBO command suite pass. A corpus case for the top-n pair needs the top-n fixture and
      is a follow-up.
- Behavior changed: Yes - a computed column above a top-n or a limit is bound to that producer.
- Does this need documentation: No

…ural key

### What problem does this solve?

Problem Summary: the canonical renderer sorts the operands of a commutative expression, but the
structural key wrote the children of every expression in their written order. `NormalizeBinaryPredicatesRule`
and `SimplifyComparisonPredicate` only commute constant-left comparisons, so `Filter(t.a = t.b)` and
`Filter(t.b = t.a)` rendered one struct and hashed two: a pinned row count copied from one query was not
found by the query which only reverses the two columns.

The structural key now normalizes the operators the renderer already recognizes as order insensitive
(equality, null safe equality, and, or): each child is serialized on its own, the child keys are sorted by
their unsigned bytes, and the sorted keys are written length prefixed. The code does not read the rendered
text, so two operands whose text would tie still have a deterministic order. The corpus fingerprints of
plans whose written operand order differed from the sorted one move once.

### Release note

An hbo statistics entry of a plan with a commutative expression inside a filter or a join condition is no
longer sensitive to the written operand order.

### Check List (For Author)

- Test: Unit Test
    - A test asserts `Filter(t.a = t.b)` and `Filter(t.b = t.a)` share the fingerprint in both literal
      modes; the regenerated corpus (70 fingerprint lines) and 201 cases of the stats package plus the
      HBO command suite pass. The regression suites were not re-run against a FE rebuilt from this commit.
- Behavior changed: Yes - the structural key sorts the children of a commutative expression.
- Does this need documentation: No

### What problem does this solve?

Problem Summary: a temporary partition is a short lived copy which a manual job replaces, and the queries
which read one are rare, so a key recorded for it is not worth the risk of a stale match; the partition
identity was also not part of the scan key in every path, which made two scans of one table differ in
places but match in others.

An olap scan whose selected partitions contain a temporary partition now refuses the description with the
reason `temporary partition of <table>`, like a tablesample does: no struct info, no fingerprint and
therefore no pinned or learned entry is generated for that sub tree, and nothing it feeds into can be
applied. The refusal is reported by EXPLAIN and by the `HBO SHOW` verdicts.

### Release note

An hbo statistics entry is no longer injected for a query which reads a temporary partition.

### Check List (For Author)

- Test: Unit Test
    - 202 cases of the stats package and the HBO command suite pass. A case with a temporary partition
      needs the olap table fixture of the catalog tests and is a follow-up.
- Behavior changed: Yes - a scan of a temporary partition is refused instead of being given a key.
- Does this need documentation: No

### What problem does this solve?

Problem Summary: `PhysicalStorageLayerAggregate` (the wrapper a count-on-index plan puts over the scan it
reads) was described as a node kind of its own, so the canonical string of the filter above it named the
scan (`F{...}(A{sl,op=COUNT_ON_MATCH}(S{t}))`) while the structural summary of that filter recognized
neither the wrapper nor its embedded relation: the wrapper is a catalog relation without children, so
`summaryOf` fell through both of its leaf branches and produced an empty summary. The pinned entry
lookup uses the summary as its necessary condition, so a pin copied from the EXPLAIN of that filter
registered the relation and was then rejected by the prefilter before its fingerprint was compared - the
entry was stored and never applied.

The hbo information of the wrapper is now the one of the relation it embeds: the description of the
group is the description of that scan, and the summary counts it as one scan of that table. The wrapper
itself is still not published or advertised (its translator delegates to the embedded relation and the
read side applies statistics at filter/join/aggregation nodes only), but the filter above it now has a
summary which matches its canonical string, so its pin can be found.

### Release note

A pinned hbo statistics entry of a filter above a count-on-index plan is applied again.

### Check List (For Author)

- Test: Unit Test
    - The stats package, the golden corpus and the HBO command suite pass. A dedicated unit case which
      builds a `PhysicalStorageLayerAggregate` still needs the physical-scan harness (no
      `PlanConstructor` helper for it yet) and is left for a follow-up.
- Behavior changed: Yes - the canonical string of a group whose node is the storage wrapper is the scan
  it reads, and the fingerprints of those groups moved once.
- Does this need documentation: No

### What problem does this solve?

Problem Summary: five fields of the structural key were written in a form which cannot be read back, so
two structures the key is supposed to separate collided (or an equivalent one was split):

1. A slot's qualifier was joined with `.` (`[cat,x.y,z]` and `[cat,x,y.z]` both became `cat.x.y.z`, two
   groups against one for a grouping over such a slot).
2. A variant sub path was joined with NUL, so the base column (`[]`) and the empty key (`[""]`) both
   became the empty string (`IsNull(v)` keeps one row of t.v={SQL NULL,{"":1},{"a":2}}, `IsNull(v[''])`
   keeps two).
3. A string literal's type (VARCHAR(4) for '%x_%', VARCHAR(7) for '%long_%') was written even in the
   NO_LITERAL key, so the constant agnostic key of two patterns of different length still differed.
4. The operand of an expansion pair was written raw, so a quoted column name containing `),col(` could
   forge the boundary between two operands.
5. The nested function of `ForEachCombinator` is a field, not a child, so `min_foreach` and `max_foreach`
   had the same identity although they keep different groups.

A qualifier and a sub path are now counted sequences of length prefixed components; a string literal folds
its type to VARCHAR in the NO_LITERAL key; an operand escapes `%`, `,` and the parentheses before the pair
text is assembled; and a for each combinator writes the name of its nested function (`min_foreach`).

### Release note

Hbo statistics keys distinguish quoted identifier components, variant sub paths, string patterns of
different length and aggregate combinators of different nested functions.

### Check List (For Author)

- Test: Unit Test
    - The regenerated corpus (142 fingerprint lines) and 202 cases of the stats package plus the HBO
      command suite pass. The paired fingerprint fixtures for the qualifier and variant cases need file
      scan and variant slot fixtures and are follow-ups.
- Behavior changed: Yes - the five fields above are encoded without ambiguity.
- Does this need documentation: No

…ax_foreach

The two combinators are one class with a nested aggregate function field, so the key has to write the nested function name; the paired filter over the aggregate now asserts the fingerprints differ in both literal modes.

### What problem does this solve?

Problem Summary: the description refused a `LogicalOlapScan` with a table sample, but a storage layer
aggregate embeds a `PhysicalOlapScan`, and a sampled physical scan passed the check: the sample reads a
random subset, different on every execution, so a row count recorded under it cannot be reused - and the
storage aggregate is described as the scan it embeds, so it inherited the sample. A physical file scan
with a sample was likewise accepted, because the check also only looked at the logical file scan.

A table sample now invalidates the description for both scan classes, and a sampled `PhysicalFileScan` is
treated like a snapshot or scan params (unsupported). The reason is reported as
`tablesample of <table>`, so no struct info, fingerprint, pinned or learned entry is generated for such a
sub tree.

### Release note

An hbo statistics entry is no longer injected for a query which reads a table sample, whatever the scan
class or the operator which embeds it.

### Check List (For Author)

- Test: Unit Test
    - 203 cases of the stats package (including the new paired combinator case) plus the HBO command suite
      pass. A sampled physical scan case needs the olap scan fixture and is a follow-up.
- Behavior changed: Yes - a sampled physical scan (and a sampled physical file scan) is refused.
- Does this need documentation: No

… its columns

### What problem does this solve?

Problem Summary: the key of an outer join expansion appended the columns each side produces
(`sides:[t.k,t.v|u.k,u.w]`) to say which relation is on the preserved side. Column pruning pushes a
key-only project below the join and the project elimination passes keep it, so the same join on the same
equality read `sides:[t.k,t.v|u.k,u.w]` with `SELECT *` and `sides:[t.k|u.k]` for a key-only selection:
the equality population is identical, but a factor copied from one EXPLAIN missed the other.

An outer join now orders the operands of each equality by side - the operand of the left child is written
first - which names the preserved side without any output column, so column pruning cannot change the key
anymore. A pair which cannot name a side has no key: both operands from one child (the mirror plan applies
the condition inside the other child) and a pair whose operands are the same column (the two occurrences
are interchangeable in the key although only one of them is preserved) are refused, as the factor of such
a join would describe an orientation it cannot tell apart. The `sides` field, `sideOperands` and the output
column scan are gone.

### Release note

An hbo join expansion entry of an outer join is keyed by the join type and the side ordered equality
pairs: it no longer changes under column pruning, and an outer join whose equality pair reads one child
only has no key.

### Check List (For Author)

- Test: Unit Test
    - Paired tests pin the side ordered keys, the two refusal cases, and that a narrow (key-only) project
      below each child keeps the key; 205 cases of the stats package plus the HBO command suite pass.
- Behavior changed: Yes - the outer join expansion key loses its output columns and refuses a pair
  without a side.
- Does this need documentation: No

…ead lock

### What problem does this solve?

Problem Summary: the freshness comparison of a pinned entry called `table.getIndexIdList()` to know
whether the table has a rollup, without the table read lock. The list is a filtered copy of OlapTable's
plain index hash map, which a concurrent drop of a materialized view rewrites under the write lock, so an
HBO SHOW or DELETE STALE could throw ConcurrentModificationException and abort.

The index count is captured under the table read lock, which is released before the visible version rpc.

### Release note

HBO SHOW / HBO DELETE STALE no longer fail when a rollup or materialized view is dropped concurrently.

### Check List (For Author)

- Test: Unit Test
    - 205 cases of the stats package plus the HBO command suite pass; a coordinated reader/DDL case is a
      follow-up.
- Behavior changed: No
- Does this need documentation: No

… not loaded

### What problem does this solve?

Problem Summary: after a restart the pinned entries are loaded from the internal table. When that load
fails (the backend or the cloud compute group is unavailable), `ensurePinnedLoaded` returned normally,
so the admin caller presented the empty or partial cache as the complete set: HBO SHOW reported no stored
entries and HBO DELETE STALE acknowledged success without inspecting or deleting the persisted stale ones,
which the loader then installed later.

`ensurePinnedLoaded` now reports whether the required load completed, and `getAllPinnedPlanStatistics`
(the admin entry point) raises an error while it has not; the background loader keeps its retry loop.

### Release note

HBO SHOW and HBO DELETE STALE report an error instead of an empty result while the pinned statistics of
the FE could not be loaded.

### Check List (For Author)

- Test: Unit Test
    - 205 cases of the stats package plus the HBO command suite pass; a load failure case needs the
      internal table fixture and is a follow-up.
- Behavior changed: Yes - an incomplete initial load is an error for the admin statements.
- Does this need documentation: No

### What problem does this solve?

Problem Summary: the pinned entries are persisted with `StatisticsUtil.escapeSQL`, which doubles a
backslash assuming the standard sql mode, but the internal session of `execUpdate` inherited the global
default: with `NO_BACKSLASH_ESCAPES` a table name `t\q` was stored with two literal backslashes while the
in-memory entry kept one. After a restart the doubled name was registered as the relation key of that row,
and the identical live query was rejected before the fingerprint lookup.

The internal session now clears `NO_BACKSLASH_ESCAPES`, so both the write and every other internal
statement read the escaped values the way `escapeSQL` produces them.

### Release note

A pinned hbo entry whose structure contains a backslash (a quoted identifier, for example) keeps working
after an FE restart with NO_BACKSLASH_ESCAPES in the global sql_mode.

### Check List (For Author)

- Test: Unit Test
    - 205 cases of the stats package plus the HBO command suite pass; a restart case with a backslash
      identifier needs the persistence fixture and is a follow-up.
- Behavior changed: Yes - the internal session sql mode no longer inherits NO_BACKSLASH_ESCAPES.
- Does this need documentation: No

…ensitive

### What problem does this solve?

Problem Summary: the expression identity appends the session time zone when a function's value depends on
it, but the detection is a list plus a date-type check: a function whose argument and result are both not
date like slips through. `from_unixtime` is BIGINT to VARCHAR, so `Filter(Like(from_unixtime(t.ts),
'1970-01-01 00:%'))` over `ts = 0..3599` keeps 3600 rows in +00:00 and none in +08:00, yet the two plans
rendered one identity and one fingerprint: a pin copied in one session applied in the other, and the
unchanged scan baseline passed freshness. `current_time` returns TIME, which is not date like either,
although the session zone decides which wall clock it reads.

Both names are now in the session dependent list. The other epoch and time functions were audited:
`hour/minute/second/microsecond_from_unixtime` and `unix_timestamp` were already listed;
`now`/`current_timestamp`/`localtime` return DATETIME, and the `*_second_timestamp` family takes or returns
a date like type, so the type check covers them; `utc_time`/`utc_timestamp` read UTC and do not depend on
the session zone; `sec_to_time`, `time_to_sec`, `time_format`, `make_time`, `time_diff`, `add_time` and
`sub_time` operate on a TIME value and never read the zone.

### Release note

An hbo statistics entry of a plan whose predicate formats an epoch (`from_unixtime`) or reads the wall
clock (`current_time`) is no longer shared between sessions in different time zones.

### Check List (For Author)

- Test: Unit Test
    - A paired test pins that the same `from_unixtime` predicate has different fingerprints in +00:00 and
      +08:00; 206 cases of the stats package plus the HBO command suite pass. The `current_time` pair needs
      a TIME column fixture and is a follow-up.
- Behavior changed: Yes - two more functions carry the session time zone in their identity.
- Does this need documentation: No

… expression

### What problem does this solve?

Problem Summary: the session locale decides the day and month names a function emits, but the expression
identity only carried the session time zone. `Filter(dayname(t.d) = 'Monday')` over 1000 rows of
2024-01-01 and 1000 rows of 2024-01-02 keeps 1000 rows with lc_time_names='en_US' and none with 'de_DE',
yet both sessions rendered one identity and one fingerprint: the unchanged scan baseline passed freshness
and a pin copied in the English session overrode the German estimate.

`dayname` and `monthname` are now locale sensitive by name, and a format based conversion (`date_format`,
`from_unixtime`, `str_to_date`, `time_format`) is locale sensitive when its format argument names a month
or a weekday (`%M`, `%W`, `%a`, `%b`) or cannot be inspected because it is computed at run time; a call
without a format argument keeps its key. The session locale is appended to the identity next to the time
zone (`DayName<de_DE>`, `FromUnixtime<+08:00|en_US>`), read from the session which plans the query.

### Release note

An hbo statistics entry of a plan whose expression prints a day or month name is no longer shared between
sessions with different lc_time_names.

### Check List (For Author)

- Test: Unit Test
    - A paired test pins that `dayname(d) = 'Monday'` has different fingerprints with en_US and de_DE;
      207 cases of the stats package plus the HBO command suite pass. The pin reuse pair and the format
      argument cases need their own fixtures and are follow-ups.
- Behavior changed: Yes - a locale sensitive function carries the session locale in its identity.
- Does this need documentation: No