Cjl/litt integration

[cody-littley]

Describe your changes and provide context

• Make it so that LittDB is included in the regular build system.
• Fixed all of the lint errors exposed by integrating the build.
• Causes CI to run LittDB tests.
• sabled some tests that were pulling in a docker dependency. The tests were slow, mildly flaky, and the features they covered are not important to our use case.

Testing performed to validate your change

unit test coverage, not yet used in prod

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	May 14, 2026, 3:48 PM

[codecov]

Codecov Report

❌ Patch coverage is 65.45455% with 38 lines in your changes missing coverage. Please review.
✅ Project coverage is 58.94%. Comparing base (d56b207) to head (1722a7c).

Files with missing lines	Patch %	Lines
...i-db/db_engine/litt/benchmark/benchmark_metrics.go	0.00%	13 Missing ⚠️
...ei-db/db_engine/litt/benchmark/benchmark_engine.go	0.00%	9 Missing ⚠️
sei-db/db_engine/litt/util/pprof.go	0.00%	4 Missing ⚠️
sei-db/db_engine/litt/littbuilder/build_utils.go	57.14%	3 Missing ⚠️
sei-db/db_engine/litt/util/ssh.go	0.00%	3 Missing ⚠️
sei-db/db_engine/litt/cli/table_info.go	0.00%	2 Missing ⚠️
sei-db/db_engine/litt/benchmark/data_tracker.go	88.88%	1 Missing ⚠️
...b_engine/litt/disktable/segment/segment_scanner.go	80.00%	0 Missing and 1 partial ⚠️
...-db/db_engine/litt/disktable/segment/value_file.go	87.50%	0 Missing and 1 partial ⚠️
sei-db/db_engine/litt/util/file_utils.go	83.33%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3435      +/-   ##
==========================================
- Coverage   59.30%   58.94%   -0.36%     
==========================================
  Files        2118     2176      +58     
  Lines      175556   181526    +5970     
==========================================
+ Hits       104108   107008    +2900     
- Misses      62383    64935    +2552     
- Partials     9065     9583     +518     

Flag	Coverage Δ
sei-chain-pr	48.55% <65.45%> (?)
sei-db	70.62% <ø> (+0.21%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
sei-db/db_engine/litt/benchmark/cohort.go	69.86% <100.00%> (ø)
sei-db/db_engine/litt/benchmark/data_generator.go	100.00% <100.00%> (ø)
sei-db/db_engine/litt/cli/benchmark.go	0.00% <ø> (ø)
sei-db/db_engine/litt/cli/litt_cli.go	0.00% <ø> (ø)
sei-db/db_engine/litt/cli/ls.go	57.40% <ø> (ø)
sei-db/db_engine/litt/cli/main.go	0.00% <ø> (ø)
sei-db/db_engine/litt/cli/prune.go	43.51% <100.00%> (ø)
sei-db/db_engine/litt/cli/push.go	0.00% <ø> (ø)
sei-db/db_engine/litt/cli/rebase.go	59.73% <ø> (ø)
sei-db/db_engine/litt/cli/sync.go	0.00% <ø> (ø)
... and 48 more

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[blindchaser]

[SUGGESTION] nolint:gosec for InsecureIgnoreHostKey() understates the risk

The comment says "overridden when knownHosts provided", but if a caller passes knownHosts == "" the insecure callback is what's actually used. This is pre-existing behavior, but if you're going to suppress the lint here, the nolint comment should reflect that fact (e.g. "intentional fallback; callers must supply knownHosts in production"), or — better — refuse to construct the session without knownHosts. Not introduced by this PR, but it's now being silenced rather than fixed.

[blindchaser]

unit.MB is defined as 1024 * 1024 in sei-db/common/unit/data_units.go, which matches docker/go-units.MiB, so all sizes/throughputs are preserved. However, naming a 2^20 constant MB is the opposite of the SI convention and will eventually trip someone up. Not blocking — just worth a doc comment on the constant if you can't rename.

[blindchaser]

uint8(shard) is justified only because shard < ShardingFactor ≤ MaxShardingFactor = 256. The comment says "shard <= 255" which is right, but if a corrupted metadata file ever deserializes a shardingFactor > 256, this will silently truncate rather than fail loudly. Consider asserting shardingFactor <= MaxShardingFactor in loadMetadataFile/deserialize.

[blindchaser]

uint64(ttlNanoseconds) and time.Duration(uint64) round-trip is fine, but TTL is signed; a negative TTL would deserialize to a huge positive duration. Probably impossible in practice, but worth validating TTL > 0 on load